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1  INTRODUCTION 


1.1  PURPOSE  OF  THIS  REPORT 

The  purpose  of  this  report  is  to  present  some  of  the  new  con¬ 
cepts  of  information  resource  management  to  the  Command  Group,  pro¬ 
gram  managers,  and  functional  managers  of  the  Army  Aviation  Research 
and  Development  Command  (AVRADCOM) . 

In  recent  years  many  large  companies  and  government  agencies 
have  come  to  view  information  as  one  of  an  organization's  important 
resources,  along  with  its  personnel,  finances,  physical  plant,  etc. 

To  reflect  this  new  awareness,  the  phrase  "information  resource  man¬ 
agement"  now  appears  in  technical  and  business  journals,  in  the  ti¬ 
tles  of  seminars,  and  in  reports  from  Federal  executive-level  study 
groups • 

The  set  of  functions  which  are  within  the  domain  of  information 
resource  management  is  large,  is  in  a  state  of  flux,  and  is  often 
controversial.  What  is  generally  agreed  to,  however,  is  that  the  set 
of  functions  should  reflect  each  organization's  own  corporate-wide 
understanding  of  Che  kind  of  Information  needed  and  how  it  is  to  be 
used  in  the  decision-making  process. 

Within  Information  resource  management,  an  emerging  concept  is 
that  of  the  "corporate  database,"  and  one  essential  function  is  that 
of  database  administration.  The  most  important  computing  software 


tools  are  known  as  Data  Base  Management  Systems  (DBMS)  and  Data 
Dictionary/Dlrectoties  (DD/D). 


From  the  perspective  of  information  as  a  corporate  resource, 
data  which  are  essential  for  management  must  be  shared  throughout  an 
organization,  must  be  consistent  and  accurate,  and  must  be  available 
for  rapid  response  to  ad  hoc  queries.  With  today's  computing  soft¬ 
ware,  dedicated  to  database  management,  a  corporate  database  and  ef¬ 
ficient,  centralized  database  administration  are  technically  feasi¬ 
ble.  With  good  management,  they  are  possible. 

The  views  presented  here  are  taken  directly  from  the  published 
literature.  The  body  of  the  report  is  intended  to  show  a  consensus 
(where  one  exists)  of  writers  and  organizations  which  have  experience 
in  information  resource  management  and/or  database  administration. 
Appendix  A  contains  the  direct  quotations  upon  which  most  of  the  re¬ 
port  is  based.  In  general  these  are  succinct  and  emphasize  the  fact 
that  the  new  era  of  information  resource  management  requires  organi¬ 
zations  to  plan  for  substantial  changes  in  their  management  of  data. 

The  actual  quotations  are  more  powerful  persuaders  than  a  sum¬ 
mary  could  be  and,  therefore,  AVRADCOM  managers  and  other  readers  are 
urged  to  study  Appendix  A. 

The  last  section  of  the  report  presents  some  steps  which  need  to 
be  taken  by  top  management  before  beginning  a  detailed  plan  for 
AVRADCOM' s  information  resource  management  or  its  database  adminis- 
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tration  function 


1.2  BACKGROUND 

In  May,  1977,  the  Data  Base  Management  System  (DBMS)  known  as 

SYSTEM  2000  was  installed  on  the  DARCOM  Midwest  Regional  Scientific 

< 

and  Engineering  Computer  (i.e.,  the  S&E  computer)  which  is  supported 
by  "subscribers"  and  "casual  users."  The  S&E  computer  is  operated  by 
the  Directorate  for  Management  Information  Systems  of  the  Troop  Sup¬ 
port  and  Aviation  Readiness  Command  (TSARCOM/DMIS) .  It  is  the  com¬ 
puter  used  for  all  of  AVRADCOM's  database  applications,  and  this  copy 
of  SYSTEM  2000  is  the  only  true  DBMS  used  by  AVRADCOM  at  this  time. 

The  first  training  for  AVRADCOM  users  was  given  in  late  Febru¬ 
ary,  1978.  During  that  course  there  were  a  few  clues  that  database 
management  was,  somehow,  new;  however,  the  general  impression  was 
that  SYSTQ1  2000  is  essentially  one  more  software  package  now  availa¬ 
ble  to  individuals  or  functional  elements  which  have  databases  they 
wish  to  store  and  query.  This  is  the  manner  in  which  the  package  is 
still  used  even  though  the  best  use  of  a  DBMS  extends  far  beyond  such 
individual  applications. 

In  May,  1978,  the  Scientific  and  Engineering  Computing  Branch 
(known  then  as  SECO,  the  Scientific  and  Engineering  Computational  Of¬ 
fice)  set  out  to  determine  what  manuals  would  be  required,  what  addi¬ 
tional  training  would  be  needed,  and  what  the  best  use  of  SYSTEM  2000 
would  be  for  all  of  AVRADCOM.  Arrangements  were  made  for  AVRADCOM 


personnel  to  attend  the  three  courses  given  by  the  Army  Management 
Engineering  Training  Agency  (AMETA) .  A  continuing  dialog  was  estab¬ 
lished  with  the  system  vendor,  MRI  System  Corporation  (now  a  part  of 
INTEL  Corporation).  AVRADCOM  joined  the  DBMS  Users'  Group  sponsored 
by  US  Army  Materiel  Development  and  Readiness  Command  (DARCOM) . 

A  review  of  the  technical  and  management  literature  was  ini¬ 
tiated.  It  was  found  that  database  management  is  moving  into  an  en¬ 
tirely  new  era,  with  new  software  technology  and  tools  and  with  new 
management  concepts.  In  fact,  most  of  the  reading  is  positively 
startling  in  its  implication  that  AVRADCOM  (and  perhaps  most  of 
DARCOM)  is  entering  this  era  without  a  clear  understanding  of  the  po¬ 
tential  for  database  management  or  of  the  experiences  and  recommenda¬ 
tions  of  other  organizations. 

A  typical  quotation  from  the  literature  (Ref  2,  Page  5): 

...  users  of  database  technology  have  learned... 
that  they  should  have  set  up  the  data  administration 
function  even  before  they  installed  a  data  dictio¬ 
nary,  and  have  both  installed  prior  to  the  installa¬ 
tion  of  the  DBMS. 

AVRADCOM  has  not  yet  established  the  data  administration  func¬ 
tion.  AVRADCOM  does  not  yet  have  a  data  dictionary. 

1.3  SOURCE  MATERIAL 

The  literature  which  was  used  as  the  basis  for  this  study  is 
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listed  in  the  bibliography.  Appendix  C.  These  articles  and  texts 
were  encountered  in  the  course  of  a  broad  search;  they  were  not  se¬ 
lected  because  they  support  a  particular  point  of  view. 


The  sources  include  a  few  text  books,  traditional  computing 
journals  (Datamation,  Journal  of  Systems  Management,  EDP  Analyzer, 
etc.),  and  government  reports  from  the  General  Accounting  Office, 
Bureau  of  Standards,  Department  of  the  Army  Headquarters,  and  other 
agencies.  Those  who  wish  to  read  a  small  sample  are  directed  to  Ref¬ 
erences  1,  4,  16,  19,  and  36. 

The  quantity  of  literature  being  published  on  this  subject  is 
escalating,  so  that  it  is  not  practical  to  postpone  important  deci¬ 
sions  while  trying  to  read  "everything."  At  the  same  time,  in  the 
references  listed,  the  single  discovery  which  we  believe  to  be  of 
major  Interest  is  that  there  are  no  significant  differences  of  opin¬ 
ion  among  government,  academic,  or  business  writers  concerning  what 
needs  to  be  done  or  the  management  difficulties  encountered  in  doing 
it. 
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2  INFORMATION  AS  A  CORPORATE  RESOURCE 


Current  writers  are  generally  consistent  in  emphasizing  that 
data  —  and  information  derived  from  data  —  constitute  a  corporate 
resource  and  should  be  managed  as  such. 

Most  writers  now  use  the  phrase  "corporate  database"  to  mean 
that  collection  of  data  which  is  managed  by  one  functional  element 
for  the  use  of  the  entire  organization  and,  in  particular,  to  aid 
managers  in  the  decision-making  process.  Technically,  the  corporate 
data  may  be  stored  in  file  cabinets,  computers,  or  whatever;  however, 
the  emphasis  here  is  on  the  management  of  the  corporate  data  using  a 
Data  Base  Management  System  (DBMS).  In  this  report  the  individual 
who  manages  the  corporate  data  is  called  the  Information  Resource 
Manager  (1RM) .  More  will  be  said  of  other  possible  titles  in  Section 
5.2. 

The  concept  of  data  as  a  corporate  resource  comes  from  the  fact 
that  the  users  of  data  are  located  throughout  the  organization,  not 
just  in  the  department  (division,  directorate,  etc.)  which  is  the 
source  for  the  data.  While  this  is  surely  not  a  new  situation,  the 
ever-increasing  sophistication  in  the  technology  of  data  storage  and 
retrieval  has  induced  a  massive  increase  in  the  quantity  of  data 
which  are  stored,  a  massive  increase  in  the  number  of  questions  asked 
about  the  data,  and  a  general  frame  of  mind  (at  least  wherever  a  com- 


puter  is  used)  that  the  answers  should  arrive  almost  instantly  and  be 
based  on  data  which  are  up-to-date  and  accurate. 

The  principal  difference  between  traditional  management  informa¬ 
tion  systems  and  the  corporate  database  is  one  of  purpose.  Manage¬ 
ment  information  systems  are,  in  general,  collections  of  data  files 
which  maintain  historical  records  about  the  organization's  other  re¬ 
sources  (personnel,  finances,  material,  etc.).  They  are  used  to  pro¬ 
duce  specific  printed  reports.  Requesting  new  information  from  them 
is  slow  and  cumbersome. 

In  contrast,  the  corporate  database  is  designed  to  help  the 
decision-making  process.  Since  this  is  a  real-time  process,  data  and 
information  must  be  available  for  response  to  ad  hoc  queries,  many  of 
which  include  projections  into  the  future  —  queries  from  the 
infinite  set  of  "what-if"  questions. 

For  reasons  sketched  above,  it  is  becoming  intolerable  to  trans¬ 
mit  requests  for  data  down  the  sequence  of  line  managers  co  workers 
who  access  independent  computer  files  (or  file  cabinets)  maintained 
in  different  functional  groups  and  then  pass  the  data  back  up  the 
line  to  the  requestor.  A  DBMS  and  its  proper  management  can  replace 
this  slow  and  unreliable  process. 

While  it  is  usually  agreed  that  a  decision  to  manage  information 
as  a  corporate  resource  infers  the  creation  of  a  corporate  database, 
there  are  few  well-accepted  rules  for  determining  exactly  what  data 
elements  it  should  contain.  Some  advocate  a  top-down  approach:  De- 


tennine  directly  from  top  management  what  information  is  needed  to 
help  the  decision-making  process  and  limit  the  database  to  those  ele¬ 


ments  which  are  actually  required  for  this  purpose.  (More  will  be 
said  of  this  in  the  next  chapter.)  Some  advocate  a  bottom-up 
approach:  The  corporate  database  should  contain  every  data  element 
which  is  useful  to  more  than  one  functional  group  of  the  organization 
or,  perhaps,  every  element  which  is  allowed  to  be  accessed  through 
the  organization's  DBMS. 

Selecting  the  rules  for  determining  the  specific  contents  of  the 
corporate  database  is  obviously  an  important  step  in  the  planning 
process. 


3  THE  INFORMATION  REQUIREMENTS  OF  MANAGEMENT 

3.1  LEVELS  OF  MANAGEMENT 

In  the  June,  1979,  issue  of  EDP  ANALYZER  (Ref  14),  Barbara 
McNurlin  considers  methods  for  finding  answers  to  the  question,  "What 
Information  Do  Managers  Need?"  As  background  for  discussing  two  spe¬ 
cific  methods,  she  refers  to  Robert  Anthony's  well-known  book  (Ref 
33)  on  planning  and  control  processes. 

Anthony  identifies  three  primary  Internal  planning  and  control 
processes  in  organizations:  (1)  stategic  planning,  (2)  management 
control,  and  (3)  operational  control. 

In  this  model  (which  is  also  discussed  in  Ref  10),  decisions 
concerning  strategic  planning  are  made  by  the  top-level  general  man¬ 
agers;  decisions  concerning  management  control  are  made  by  middle- 
level  functional  managers  and  the  general  managers;  decisions  con¬ 
cerning  operational  control  are  made  by  operational  managers  and  the 
functional  managers. 

The  "processes”  are  well-defined  in  Anthony's  book  and  need  not 

be  repeated.  Important  to  this  study  is  the  fact  that  he  identifies 

"information  handling"  as  an  independent  process  and  says  that  it 

must  be  carefully  distinguished  from  the  others: 

Information  handing  is  the  process  of  collecting, 
manipulating,  and  transmitting  information,  whatever 
its  use  is  to  be. 

He  shows  an  information  system  which  operates  apart  from  the 
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management  structure.  This  system  collects  data  from  all  management 
levels  and  supplies  information  to  all  levels. 

Although  this  view  is  over  15  years  old  and  predates  widespread 
use  of  a  DBMS,  the  emphasis  on  managing  the  information  apart  from 
its  particular  use  is  only  recently  gaining  general  acceptance. 

According  to  McNurlin  (Ref  14,  Page  4),  the  typical  management 
information  system  (MIS)  designed  during  the  past  10-15  years  at¬ 
tempted  to  gather  and  store  enormous  quantities  of  data  generated  at, 
and  for  the  use  of,  the  level  of  operational  control.  It  was  as¬ 
sumed,  then,  that  the  information  needed  for  the  two  higher  levels  of 
management  could  be  generated  from  summaries  of  these  data.  This  is 
the  traditional  bottom-up  approach. 

McNurlin  states  that  recent  writers  on  decision-support  systems 
claim  that  higher  levels  of  management  do  not  use  this  kind  of  MIS 
even  when  it  exists  within  their  organization,  but  rather  that  they 
require  a  top-down  system  which  can  be  designed  only  after  investiga¬ 
ting  what  kinds  of  decisions  are  actually  made  and  what  information 
is  needed  as  an  aid  for  making  these  decisions. 

3.2  TOP-DOWN  ANALYSIS  OF  INFORMATION  REQUIREMENTS 

McNurlin  (Ref  14)  presents  a  summary  and  comparison  of  two  spe¬ 
cific  top-down  approaches  used  to  determine  the  information  require¬ 
ments  of  management. 

One  of  these  approaches  is  called  the  CSF  method.  It  is  based 


I 


10 


on  an  identification  of  "critical  success  factors"  and  was  developed 
by  John  Rockart  at  MIT's  Center  for  Information  Systems  Research  (Ref 
24).  The  second  method  is  called  BSP  (Business  Systems  Planning)  and 
was  developed  by  IBM  (Ref  25). 

It  would  not  be  useful  to  attempt  to  describe  the  details  of 
these  two  approaches;  however.  It  Is  useful  to  list  some  of  their 
similarities  and  differences: 

a.  The  output  of  each  method  is  knowledge  of  the  organization's 
information  requirements.  With  this  knowledge,  an  "informa¬ 
tion  planning  team"  can  construct  the  plan  for  providing  the 
desired  information  and  for  designing  the  corporate 
database. 

b.  To  ensure  a  high  probability  of  success,  both  methods  re¬ 
quire  the  involvement  —  as  well  as  the  support  —  of  the 
highest  level  of  management. 

c.  The  CSF  method  finds  the  "critical  success  factors"  for 
each  individual  manager.  It  assumes  the  information  require¬ 
ments  are  functions  of  the  personality  and  style  of  these 
individuals  as  well  as  their  management  duties  and,  there¬ 
fore,  these  requirements  change  with  time  as  the  managers 
change.  The  BSP  method  is  directed  more  at  the  mission  of 
the  different  levels  of  management  and  concentrates  on  the 
two  top  levels. 
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d.  A  CSF  study  is  said  to  require  less  time,  providing  the  in¬ 
dividual  managers  are  responsive. 

e.  The  BSP  method  is  more  structured  than  the  CSF  method  and 
provides  more  detailed  information  as  a  starting  point  for  a 
corporate  database. 

3.3  EXPERIENCE  WITH  TOP-DOWN  TECHNIQUES 

The  authors  of  both  methods  referred  to  in  the  above  section 
state  that  these  methods  have  been  used  with  success  by  many  organi¬ 
zations.  IBM  claims  (Preface  to  Ref  25)  that  "hundreds  of  studies 
have  been  completed  successfully  using  [the  BSP]  approach."  Rockart 
(Ref  24)  presents  experiences  of  five  specific  cases  with  CSF. 

McNurlin  (Ref  14)  presents  some  details  from  one  company's  expe¬ 
rience  with  the  use  of  the  BSP  method  and  another  using  CSF.  There 
were  several  interesting  similarities: 

a.  Both  organizations  had  data  processing  departments,  but  both 
found  the  information  requirements  of  their  mid-level  and 
top-level  managers  were  not  being  met  by  the  existing  MIS. 

b.  In  each  organization  a  high-level  manager  took  an  active 
part  in  the  team  which  was  formed  to  determine  the  informa¬ 
tion  requirements. 

c.  Each  organization  brought  in  consultants  to  help  direct  the 
use  of  the  method  they  chose . 

d.  Each  organization  established  a  new  position  of  "information 
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planning  executive"  outside  the  existing  data  processing  de¬ 
partment. 

We  believe  the  evidence  is  clear  that  any  organization,  in¬ 
cluding  AVRADCOM,  should  decide  first  what  level(s)  of  management  are 
to  be  served  by  the  corporate  database,  then  what  information  is 
needed  at  these  levels,  and  finally  what  data  are  needed  for  the  nec¬ 
essary  information.  In  addition,  it  must  be  kept  in  mind  that  infor¬ 
mation  requirements  are  dynamic  and  that  the  design  of  an  equally 
dynamic  corporate  database  is  as  difficult  as  it  is  valuable. 


4  COMPUTER  SOFTWARE  AND  NECESSARY  TECHNICAL  EXPERTISE 

4.1  DATA  DICTIONARY/DIRECTORY 

The  data  dictionary  contains  information  about  data  which  are 
stored  in  the  databases.  If  it  is  automated ,  the  dictionary  itself 
is  a  database.  Since  consistent  phraseology  would  lead  from  the 
clear  terms  of  "personnel  data,"  "financial  data,"  "inventory  data," 
etc.,  to  the  awkward  "data  data,"  the  term  "metadata"  appears  in  the 
literature  to  mean  the  data  which  describe  the  data.  The  data  dic¬ 
tionary,  then,  is  the  database  which  contains  metadata. 

The  most  basic  data  in  the  data  dictionary  describe  individual 
data  elements  which  occur  in  one  or  more  databases.  The  description 
of  each  data  element  must  be  accurate,  complete,  and  unambiguous.  It 
must  contain  enough  detail  so  that  database  designers  and  users  can 
distinguish  absolutely  between  similar  data  elements. 

The  data  directory  also  Identifies  all  application  programs 
which  use  each  data  element.  Since  more  than  one  user  will  access  an 
individual  database,  the  directory  is  essential  for  determining  the 
effect  that  a  proposed  change  to  a  data  element  will  have  on  the  ap¬ 
plication  programs. 

There  are  several  commercial  software  packages  which  provide  a 
Data  Diet ionary /Directory  (DD/D).  In  the  most  desirable  situation, 
the  dictionary/directory  is  independent  of  any  DMBS  used  for  the  cor- 
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porate  database.  As  with  all  components  of  database  management,  the 
design  of  a  dictionary /directory  Is  sophisticated  and  evolving. 

Within  the  broad  concept  of  the  corporate  database,  the  DD/b  Is 
the  single  most  Important  database.  Most  writers  believe  it  should 
be  Installed  and  Its  function  fully  understood  before  specific 
databases  are  generated . 

It  Is  not  an  easy  task,  to  maintain  the  dictionary /directory ; 
however,  It  Is  as  essential  as  a  DBMS  if  the  purpose  and  potential  of 
corporate-wide  data  and  information  management  are  to  be  realized. 


4.2  DATA  BASE  MANAGEMENT  SYSTEMS 

It  has  been  pointed  out  that  the  Data  Base  Management  System 
(DBMS)  known  as  SYSTEM  2000  has  been  available  to  AVRADCOM  users 
since  May,  1977.  This  is  a  sophisticated  software  package  developed 
by  the  INTEL  Corporation.  There  are  several  other  systems  available 
from  commercial  sources  today,  and  it  is  obvious  that  there  will  be 
many  more  in  the  near  future. 

As  with  all  software  packages,  a  DBMS  evolves  with  new 
enhancements,  major  revisions,  and  complete  redesigns.  Some  changes 
are  the  result  of  users'  experiences;  some  are  the  result  of  major 
changes  in  computer  hardware  and  computer  operating  systems;  some  are 
the  result  of  new  understandings  of  the  mathematics  which  describe 
the  algorithms  used  for  data  storage  and  retrieval* 

At  this  time  there  are  three  fairly  distinct  models  used  to  rep- 
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resent  database  organization:  network,  hierarchical,  and  relational* 
Each  of  today's  commercial  packages  is  developed  to  handle  one  of 
these  types  of  data  structure.  For  instance,  the  major  IBM  package 
uses  a  network  model  while  SYSTEM  2000  uses  a  hierarchical  model. 

Each  model  has  its  supporters  and  its  detractors.  Ideally,  the 
choice  of  which  descriptive  system  (and  then  which  DBMS)  to  use  would 
come  after  an  understanding  of  the  most  probable  use  of  the  database. 
For  example,  one  type  of  DBMS  would  be  best  for  a  large  database 
which  is  updated  continuously  but  subject  to  very  few  ad  hoc  queries 
while  a  different  type  would  be  best  for  a  database  which  has  infre¬ 
quent  updates  but  is  subject  to  many  ad  hoc  queries. 

It  is  not  important  for  the  reader  of  this  report  to  understand 
—  or  even  to  know  —  the  technical  differences  among  the  DBMS  pack¬ 
ages.  It  is  important  to  appreciate  that  each  DBMS  changes  with  time 
and  that  packages  in  addition  to  SYSTEM  2000  will  be  used  eventually 
by  AVRADCOM.  It  is  important  to  recognize  that  efficient  use  of  any 
DBMS  requires  specific  technical  expertise  and  careful  and  continuous 
management  in  order  to  minimize  the  disruption  of  the  users  as  the 
systems  evolve. 

4.3  OTHER  SOFTWARE 

Although  the  Data  Dictionary/Directory  (DD/D)  and  Data  Base  Man¬ 
agement  Systems  (DBMS)  are  the  software  packages  which  have  the  high¬ 
est  visibility  and  are  the  subject  of  the  most  conversation  and  even 


controversy,  they  are  not  the  onLy  packages  which  are  essential  in 
the  database  environment. 

If  the  DD/b  is  not  an  integral  part  of  the  DBMS,  software  is  re¬ 
quired  to  connect  the  two.  If  the  DD/D  is  an  integral  part  of  a  DBMS 
and  if  more  than  one  DBMS  is  used,  software  is  required  to  communi¬ 
cate  between  the  DBMSs. 

If  the  technology  continues  to  move  towards  real  independence 
between  application  programs  and  the  corporate  database,  software 
will  be  required  as  an  interface  between  the  applications  and  the 
DBMS. 

Report  generators  will  become  more  important  as  the  database  be¬ 
comes  more  useful  for  decision-support.  Graphics  packages  will  be 
used  with  ad  hoc  queries. 

As  the  DBMS  becomes  even  more  sophisticated,  it  is  anticipated 
that  using  it  efficiently  will  require  considerable  understanaing  of 
the  computers'  operating  systems  and  user  protocols. 

In  considering  the  evolution  of  the  computer  software  which  both 
drives  and  supports  the  evolution  of  information  resource  management, 
it  is  more  important  to  accept  the  fact  that  there  are  many  complex 
components  to  the  collection  of  software  packages  than  to  attempt  now 
to  understand  the  specific  functions  of  those  components. 

4.4  TECHNICAL  EXPERTISE 

The  right  kind  and  quality  of  technical  expertise  must  be  avail- 
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able  In  order  for  the  corporate  database  to  be  useful  as  a  decision- 
support  tool.  Martin  (Ref  36,  page  267)  identifies  three  types  of 
analysts  on  the  database  administration  staff:  (1)  Data  Definition 
Analyst,  (2)  Database  Design  Analyst,  (3)  Data  Operations  Supervi¬ 
sor.  In  addition,  he  identifies  a  separate  security  officer. 

The  list  of  functions  performed  by  each  is  sufficiently  detailed 
that  it  should  be  studied  carefully  at  the  time  the  mission  and  func¬ 
tions  are  determined  for  the  staff  of  the  Information  Resource  Man¬ 
ager  (IRM).  It  is,  in  fact,  too  detailed  to  be  considered  item-by¬ 
item  in  this  report;  however,  some  comments  are  important: 

1.  It  is  impossible  to  over-emphasize  the  necessity  for  accu¬ 
rate  definitions  of  data  elements  and  the  relationships  be¬ 
tween  them.  The  person  responsible  for  the  definitions  must 
be  committed  to  translating  local  jargon  into  lucid  English. 
He/she  must  have  all  the  attributes  of  a  dedicated  technical 
writer. 

2.  In-depth  technical  knowledge  of  some  fields  of  computer  sci¬ 
ence,  software  engineering,  mathematics,  and  systems  analy¬ 
sis  will  be  needed  by  the  IRM  staff.  Since  the  hardware, 
software,  and  the  database(s)  will  evolve  continuously,  the 
real-time  function  of  decision-support  cannot  be  maintained 
by  relying  solely  on  contractors  and  consultants  for  this 
kind  of  knowledge. 

3»  The  techniques  used  for  determining  and  describing  the  re- 
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quirements,  specifications,  and  design  of  the  database(s) 
must  be  rigorous,  well-structured,  and  wel L-documented . 

4.  The  technical  staff  must  be  —  and  remain  —  fully  profes¬ 
sional*  Each  member  must  stay  in  touch  with  the  state-of- 
the-art  by  having  easy  access  to  current  journals,  texts, 
classes,  short  courses,  conferences,  and  meetings  of  users, 
designers,  and  administrators. 

Of  course  a  particular  organization  may  choose  to  assign  respon¬ 
sibility  for  the  functions  listed  by  Martin  in  some  way  other  than 
that  which  he  recommends.  Nevertheless,  most  of  the  functions  listed 
are  so  basic  that  they  will  be  performed  —  if  not  by  the  most  appro¬ 
priate  person  according  to  a  well  thought-out  plan,  then  by  the  most 
desperate  user  or  application  programmer  according  to  the  needs  of  a 
crisis! 
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5  THE  FUNCTION  OF  INFORMATION  RESOURCE  MANAGEMENT 


5.1  FEDERAL  POLICY 

In  very  recent  years  there  have  been  at  least  two  high-level 
projects  coi.cerned  specifically  with  the  federal  government's  prob¬ 
lems  with  ii  mation  management.  One  is  the  Commission  on  Federal 
Paperwork  (R«.  17,  Page  59,  and  Ref  110).  The  other  is  the  Federal 

Data  Processing  Reorganization  Project  (Ref  11,  Ref  43,  and  Ref  46). 
Both  have  submitted  reports  to  the  Office  of  Management  and  Budget 
(OMB) . 

The  major  concern  of  both  projects  is  the  enormous  burden  placed 
on  business,  industry,  and  private  citizens  to  provide  information  to 
the  government  and,  in  turn,  the  government's  own  burden  of  providing 
information  to  the  public.  Although  these  concerns  are  not  identical 
with  those  of  AVRADCOM  and  other  subordinate  commands  of  DARCOM,  many 
of  the  recommendations  from  the  two  projects  will  have  an  effect  on 
the  policies  of  information  management  within  most  government  agen¬ 
cies.  Some  of  the  recommendations  are  incorporated  in  legislation 
which  has  been  introduced  to  the  House  of  Representatives  as  H.R.6410 
(Ref  42). 

Among  the  requirements  which  should  eventually  effect  all  DARCOM 
agencies  (if  the  legislation  passes)  are:  (1)  establish  an  Office  of 
Federal  Information  Policy  within  OMB,  (2)  designate  within  each 
agency  (including,  presumably.  Department  of  Defense  (DOD)  and  De- 
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partment  of  the  Army  (DA))  "a  senior  official  who  reports  directly  to 
such  agency  head"  to  perform  specific  functions  relative  to  informa¬ 
tion  management,  (3)  establish  a  Federal  Information  Locator  System, 
and  (4)  define  more  clearly  the  obligations  of  OMB,  the  Department  of 
Commerce,  and  the  General  Services  Administration  (GSA)  in  the  Brooks 
Act  (Ref  39). 

The  vocabulary  used  in  H.R.6410  and  the  description  of  the  Fed¬ 
eral  Information  Locator  System  (Ref  17,  Page  97)  should  lead  all 
agencies  to  a  common  terminology  for  the  functions  of  information 
management  and  for  database  design  as  well  as  a  general  acceptance  of 
"information  as  a  resource." 

In  addition  to  the  proposed  legislation,  the  Commission  on  Fed¬ 
eral  Paperwork  has  sponsored  the  creation  of  a  new  job  series,  Infor¬ 
mation  Manager,  with  grades  GS-9  through  GS-15.  The  proposed  quali¬ 
fication  standard  (Ref  44,  sent  to  the  Office  of  Personnel  Management 
in  April  1979)  identifies  the  Information  Manager  as  a  "resource  man¬ 
ager."  In  general  terms,  the  responsibilities  of  this  new  manager 
can  include  all  of  those  which  appear  in  the  literature  (discussed  in 
the  following  section)  as  relevant  to  managing  a  corporate  database 
and  many  more,  such  as  libraries,  information  centers,  word  proces¬ 
sing  centers,  etc. 

From  the  level  of  AVRADCOM  on  up  the  hierarchy  of  federal  agen¬ 
cies,  those  who  are  involved  in  the  acquisition  of  computing  hardware 
are  aware  that  the  Brooks  Act  has  a  direct  effect  on  their  procure- 
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merit  procedures.  This  act  also  assigned  responsibility  for  scienti¬ 
fic  and  technical  "advisory  services"  and  data  processing  standards 
to  the  Department  of  Commerce  which  then  delegated  the  requirement  to 
its  National  Bureau  of  Standards  (NBS).  Each  NBS  report  included  in 
Appendix  C  mentions  that  fact.  Within  NBS,  the  Institute  for  Com¬ 
puter  Sciences  and  Technology  publishes  the  results  of  its  own 
studies  and  the  formal  Federal  Information  Processing  Standards 
(FIPS) . 

Congressional  hearings  (Ref  40  and  Ref  41)  in  June-Oct,  1976, 
attempted  to  assess  the  success/failure  of  the  Brooks  Act.  Although 
the  major  concern  was  hardware  procurement,  the  role  of  NBS  in  gener¬ 
ating  standards  received  considerable  attention.  In  addition  to  the 
involvement  of  OMB,  GSA,  and  NBS,  the  ubiquitous  General  Accounting 
Office  (GAO)  has  published  several  reports  (Ref  23  and  Ref  45)  which 
are  critical  of  the  management  of  software  development  and  acquisi¬ 
tion  (Including  database  systems)  by  all  levels  of  federal  agencies. 

In  the  course  of  this  study,  we  have  not  yet  encountered  current 
references  to  the  concept  of  a  corporate  database  or  the  database  ad¬ 
ministrator's  functions  from  the  DOD;  however,  there  were  DOD  repre¬ 
sentatives  on  the  two  projects  noted  above. 

At  Department  of  the  Army  Headquarters  (DA  HQS),  the  Office  of 
the  Assistant  Chief  of  Staff  for  Automation  and  Communications 
(ACSAC) ,  with  the  aid  of  a  consulting  firm,  has  completed  a  large 
study  of  its  own  requirements  for  information  management.  Reference 
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16,  "An  Information  Management  Study  for  Headquarters,  Department  of 
the  Army,"  is  the  executive  summary  of  their  findings  and  recommenda¬ 
tions.  The  terminology  used  (e.g.,  information  resource  management, 
information  locator,  decision  support)  is  consistent  with  the  other 
federal  studies  mentioned  above  and  with  the  general  literature. 

Any  organization  —  including  AVRADCOM  —  which  attempts  to 
find  an  answer  to  the  question,  "What  information  do  managers  need?," 
could  profit  from  a  thorough  look  at  the  procedure  used  by  DA  HQS  to 
find  its  own  answer  to  that  question. 

The  Air  Force  has  several  published  reports  on  database  adminis¬ 
tration,  including  Reference  6,  "The  Data  Administrator's  Handbook," 
from  the  Air  Force  Academy. 

As  this  report  is  being  written,  DARCOM/DMIS  is  looking  at  in¬ 
formation  management  and  database  administration  from  within  the  DMBS 
Users'  Group,  the  DMIS  Chiefs'  organization,  the  Scientific  and  Engi¬ 
neering  Computer  Steering  Committee,  and  the  Scientific  and  Engineer¬ 
ing  Computing  Council. 

Although  the  DARCOM  "ADP  Blueprint  for  the  80's"  (Ref  21)  does 
not  include  information  resource  management  as  one  of  the  seven  major 
"thrusts,"  it  does  emphasize  the  future  use  of  Data  Base  Management 
Systems  and  the  database  administrator's  role  in  maintaining  data  el¬ 
ement  definitions,  data  integrity,  and  data  security. 

We  have  sketchy  information  from  several  other  DA  commands  and 
subordinate  commands  which  appear  to  be  in  different  stages  of  inves- 
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tigatlng  and/or  implementing  information  resource  management*  Al¬ 
though  many  aspects  of  this  particular  field  of  management  science 
are  in  a  state  of  flux,  it  is  at  least  clear  that  all  federal  agen¬ 
cies  are  moving  toward  a  new  seriousness  about  data/information  man¬ 
agement  as  well  as  toward  new  technical  and  organizational  ap¬ 
proaches* 


5.2  THE  INFORMATION  RESOURCE  MANAGER 

The  literature  is  replete  with  suggestions  for  titles  for  all 
aspects  of  the  new  database  environment.  Among  those  offered  for  the 
person  who  has  the  highest  direct  responsibility  for  management  of 
the  corporate  database  are:  Information  Resource  Manager,  Information 
Manager,  Information  Planning  Executive,  Information  Services  Execu¬ 
tive,  Data  Base  Administrator,  Data  Base  Manager,  Data  Base  Project 
Manager,  Data  Administrator,  Global  Data  Administrator,  Enterprise 

V 

Administrator,  Application  System  Administrator,  and  Data  Locator. 

No  doubt  there  are  more. 

Those  authors  who  claim  to  be  presenting  views  based  on  actual 
experience  make  a  point  of  selecting  a  title  which  they  hope  will  em¬ 
phasize  the  fact  that  the  corporate  database  and  its  management 
should  not  be  viewed  as  Just  another  assignment  for  the  department 
which  has  traditionally  performed  the  data  processing  or  maintained 
the  management  information  systems.  Appendix  A  contains  a  sampling 


of  these  views 


In  this  report,  It  is  assumed  that  the  title  of  Information  Re¬ 
source  Manager  (IRM)  is  the  most  accurate.  As  the  references  show, 
this  title  appears  more  and  more  in  the  current  literature  and  cur¬ 
rent  government  studies.  It  also  appears  in  new  product  information 
from  vendors. 

The  specific  functions  which  are  a  part  of  managing  the  cor¬ 
porate  database  are  listed  in  the  following  section;  however,  the 
IRM's  most  important  function  is  to  establish  policies  relative  to 
the  corporation's  Information.  This  is  stated  and  explained  in  dif¬ 
ferent  ways  by  various  authors.  From  Martin  (Ref  36,  Page  261): 

The  Corporate  data  administrator  [i.e.,  the  informa¬ 
tion  resource  manager]  has  a  policy-oriented  job 
concerned  with  corporate  strategy  and  planning.  He 
should  be  high  enough  to  know  the  corporate  policies 
and  politics,  and  have  strong  powers  to  see  that  his 
strategies  are  Implemented. 

The  same  author  (Ref  36,  Page  233)  points  to  the  technical 
knowledge  required: 

The  first  event  [in  "going  database"]  should  be  the 
appointment  of  a  data  administrator  with  enough 
knowledge  and  at  a  high  enough  level  to  develop  the 
data-base  strategy  and  select  an  organization-wide 
data  description  language  and  data  dictionary. 

It  is  clear  in  the  text  that  the  author's  use  of  "select"  in  the 
sentence  above  infers  in-depth  technical  knowledge  of  the  important 
analytical  and  management  functions  rather  than  just  the  authority  to 
approve  a  recommendation  made  by  a  lower-level  technical  expert. 

Throughout  much  of  the  literature,  it  is  emphasized  that  the  in- 
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formation  resource  manager  must  have  a  combination  of  technical 


expertise  and  corporate- level  decision-making  power*  The  NBS  survey 
of  federal  database  administrators  found  (in  real  cases)  that  usually 
this  person  did  not  have  enough  decision-making  power  and  did  not 
have  enough  enforcement  power.  In  addition,  the  survey  found  that 
problems  arose  because  the  "decision-making  management  [was]  not 
knowledgeable  in  [the]  technological  state-of-the-art." 

5.3  FUNCTIONS  PERFORMED  TO  MAINTAIN  THE  CORPORATE  DATABASE 

In  order  for  the  corporate  database  to  be  a  significant  improve¬ 
ment  over  a  collection  of  computer  files  and  typical  management  in¬ 
formation  systems,  its  design  and  management  must  be  such  that  the 
technical  advantages  of  the  DBMS  software  and  the  organizational  ad¬ 
vantages  of  centralized  control  can  be  realized.  These  advantages 
include  the  ability  to: 

a.  Maximize  data  independence. 

b.  Minimize  data  redundance. 

c.  Ensure  data  integrity. 

d.  Ensure  data  reliability. 

e.  Ensure  data  security. 

Data  independence  means  that  the  application  programs  are  not 
affected  by  changes  in  the  design  or  structure  of  the  database,  or 
vise  versa.  Complete  data  independence  is  not  yet  a  reality.  It 
waits  for  even  more  sophisticated  software;  however,  good  design  of 
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Che  database(s)  and  understanding  of  Che  DBMS  by  application  program¬ 
mers  will  minimize  adverse  effects  of  changes. 

Redundant  data  implies  that  the  same  data  element  is  stored  in 
more  than  one  database  or  In  more  than  one  part  of  a  single  database. 
The  technical  experts  who  design  the  database  will  always  be  faced 
with  the  traditional  tradeoff  problem  of  choosing  to  save  computer 
storage  (i.e.,  reducing  redundancy)  or  choosing  to  save  computing 
time  (i.e.,  storing  data  automatically  in  more  than  one  way  for 
faster  access).  This  source  of  redundancy  is  not  the  major  concern. 
Redundancy  of  serious  concern  occurs  when  the  same  data  element  Is 
entered  in  more  than  one  database,  usually  by  workers  In  different 
parts  of  the  organization,  each  one  unaware  that  someone  else  Is  en¬ 
tering  the  same  data.  If  the  database  design  and  management  permit 
this,  it  is  inevitable  that  some  data  will  be  inconsistent  —  as  will 
be  the  Information  derived  from  that  data. 

Data  integrity  means  that  data  remain  correct  even  If  there  are 
software  or  hardware  failures.  Experienced  DBMS  users  have  said  that 
failure  recovery  is  the  problem  which  requires  the  most  in-depth 
technical  expertise. 

Data  reliability  means  that  the  value  stored  in  a  data  element 
is  the  value  which  is  supposed  to  be  stored  there. 

Security  means  protection  against  unauthorized  access  to  the 
database  for  any  reason,  intentional  or  accidental. 

Since  data  elements  within  the  corporate  database  are  made 
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available  for  all  approved  application  programs  and  ad  hoc  queries, 
the  IRM's  staff  must  maintain  all  essential  Information  about  the  de¬ 
scription  of  the  data  elements  and  where  they  are  used. 

In  order  to  be  the  central  source  of  knowledge  about  the 
database  and  to  take  full  advantage  of  a  sophisticated  DBMS,  the 
IRM's  staff  must  perform  many  administrative  and  technical  functions. 
Several  authors  provide  their  version  of  a  list  of  essential  func¬ 
tions.  There  are  differences  of  course,  but  most  writers  agree  that 
the  IRM's  staff  should: 

a.  Approve  the  definition  of  data  elements  —  requiring  com¬ 
pleteness  and  accuracy. 

b.  Provide  training  in  the  use  of  the  DBMS  and  the  Data 
Diet ionary /Directory . 

c.  Develop  and  publish  all  policies  and  procedures  having  to  do 
with  the  corporate  database. 

d.  Maintain  the  Data  Dictionary/Directory. 

e.  Monitor  the  use  of  the  database  in  order  to  make  design  im¬ 
provements  . 

f.  Acquire  software  and  hardware. 

g.  Determine  the  priority  for  developing  application  programs 
when  there  are  competing  requests  for  the  help  of  the  IRM's 
staf f . 

h.  Approve  access  to  the  database  for  application  programs. 
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i.  Assist  application  programmers  who  need  to  access  the 
database . 

j.  Approve  the  content  of  the  database  —  including  requests  to 
add  or  delete  data  items. 

k.  Maintain  the  record  of  who  is  responsible  for  entering  val¬ 
ues  in  the  database  and  arbitrate  disputes  about  this  re¬ 
sponsibility. 

l.  Establish  and  enforce  procedures  to  minimize  accidental  dam¬ 
age  to  the  database. 

m.  Establish  and  maintain  procedures  for  reconstructing  a  dam¬ 
aged  database. 

n.  Develop  procedures  for  assigning  responsibility  for  the  ac¬ 
curacy  of  data  values. 

o.  Assign  all  passwords  and  arbitrate  disputes  about  access  to 
the  data. 

p.  Select  and  enforce  the  use  of  a  standard  data  description 
language . 

As  the  corporate  database  evolves  and  as  designers,  users,  and 
managers  gain  experience,  the  functions  of  the  IRM  and  his/her  staff 
will  be  refined.  In  fact,  Martin  (Ref  36,  Pages  267-269)  lists  41 
distinct  functions  divided  among  three  types  of  analysts  (c.f.  Sec¬ 
tion  4.4)  and  a  security  officer. 

Since  the  corporate  database  will  be  a  resource  for  the  entire 
organization,  the  policies  and  procedures  developed  by  the  IRM  must 
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be  adhered  Co  by  all  functional  elements.  Some  authors  believe  that 
the  IRM's  authority  to  enforce  procedures  will  be  maintained  only  on 


the  basis  of  a  clear,  written  charter  which  Is  agreed  to  and  actively 
supported  by  the  highest  level  of  top  management. 


5.4  MANAGEMENT  PROBLEMS 

As  most  authors  state,  the  technical  problems  which  are  encoun¬ 
tered  In  using  a  Data  Base  Management  System,  and  In  designing  and 
Implementing  a  corporate  database  can  be  solved  by  a  competent  tech¬ 
nical  staff  which  has  access  to  good  software,  hardware,  and  train¬ 
ing.  The  problems  are  not  trivial,  but  they  are  not  more  difficult 
than  those  encountered  by  a  typical  engineering  design  group  working 
with  a  new  and  evolving  technology. 

The  success  or  failure  of  information  resource  management  (or 
the  corporate  database)  Is  said  to  depend  primarily  on  management  it¬ 
self  —  specifically  the  commitment  and  support  given  to  the  IRM  by 
top-level  management  (c.f.,  particularly.  Page  31  of  Ref  19,  Ref  2, 
Ref  8,  Ref  10,  and  Ref  36). 

It  Is  well-known  that  the  supply  of  trained  computer  scientists 
and  computer  systems  analysts  has  not  kept  pace  with  the  introduction 
of  new  and  sophisticated  hardware  and  software.  The  design  of 
database  software  Is  one  of  the  computing  technologies  evolving  at  a 
very  fast  rate.  In  addition  to  advantages  listed  previously,  then, 
there  will  be  an  overall  savings  in  high-level  technical  personnel  if 
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Che  database  is  managed  by  an  IRM  with  Che  expertise  concentrated  in 
a  single  functional  element.  The  number  of  experts  required  is  con¬ 
siderably  less  than  the  number  needed  if  each  large  functional  divi¬ 
sion  attempts  its  own  database  design  and  maintenance  with  its  own 
staff  of  database  experts. 

The  difficulties  which  will  arise  initially  with  central  design 
and  control  are  not  unique  to  the  business  of  information  management. 
They  exist  whenever  one  functional  element  is  the  primary  source  (or 
sole  source)  of  a  service  or  product  needed  by  other  functional  ele¬ 
ments.  Since  these  kinds  of  problems  are  "old  stuff"  to  large  orga¬ 
nizations,  their  solutions  are  well  known  (even  though  it  cannot  be 
taken  for  granted  that  they  are  working  well  at  any  particular  mo¬ 
ment)  . 

As  all  management  texts  and  seminars  stress,  success  in  provid¬ 
ing  a  resource  across  functional  lines  requires  the  usual  combination 
of  authority,  responsibility,  competence,  cooperation,  communication, 
and  adequate  personnel  resources. 

The  characteristics  of  information  resource  management  which 
will  make  the  early  phases  of  implementation  more  difficult  than, 
say,  inventory  management  are  (1)  the  newness  of  the  concept  and  (2) 
the  lack  of  technical  experience  (with  large  computer  software  sys¬ 
tems)  of  those  managers  outside  the  IRM's  staff  who  will  be  asked  to 
rely  on  the  services. 

It  is  reported  in  the  literature  (and  amply  illustrated  in  Ap- 
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pendix  A)  Chat  Che  Information  Resource  Manager  (or  Database  Admlnls 

trator)  encounters  considerable  difficulty  with  management-level  dif 

ferences  of  opinion.  Martin  (Ref  36,  Page  266)  is  direct: 

Too  often  the  conceptual  clarity  of  shared  databases 
becomes  clouded  by  political  warfare.  To  resolve 
the  bitter  arguements  that  ensue  the  data-base  ad¬ 
ministrator  must  have  considerable  diplomacy  and  au¬ 
thority. 

But  What  is  there,  really,  to  disagree  about?  A  short  list  of 
reported  controversies  includes: 

a.  Differences  of  opinion  among  managers  about  the  desired  con 
tents  of  the  corporate  database. 

b.  Differences  of  opinion  among  managers  about  who  "owns"  par¬ 
ticular  data  values. 

c.  Differences  of  opinion  among  managers  about  who  should  be 
allowed  to  read  particular  data  values. 

d.  Differences  of  opinion  among  managers  about  who  should  load 
and  update  particular  data  elements. 

e.  Differences  of  opinion  among  managers  about  whose  applica¬ 
tion  program  has  highest  priority  for  the  help  of  the  IRM 
staff . 

f.  Differences  of  opinion  between  the  IRM  and  other  managers 
about  the  quality  of  documentation  required  by  the  IRM's 
staff  or  provided  by  the  IRM's  staff. 

Resolution  of  these  and  other  conflicts  requires  considerable 
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diplomatic  skill  from  the  IRM  and  his/her  staff.  Still,  there  re¬ 
mains  the  potential  for  the  effective  destruction  of  the  IRM's  func¬ 
tion  since  it  is  often  human  nature  for  the  manager  who  perceives 
that  he/she  has  "lost"  one  of  the  above  arguements  to  decide,  "I'll 
do  it  myself,  my  own  way,  in  my  own  shop!"  It  is  at  this  time  that 
top  management  must  re-confirm  its  commitment  and  prevent  the 
fragmentation  of  the  corporate  database  into  the  old  system  of  indi¬ 
vidual,  disjoint,  inconsistent,  and  redundant  computer  files. 

Martin  has  summed  up  his  views  on  causes  of  success  and  failure 
in  his  EPILOGUE:  HOW  TO  SUCCEED.  This  is  included  as  Appendix  B. 
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6  INITIAL  ACTION  REQUIRED  BY  TOP  MANAGEMENT 


Once  the  corporation  has  made  the  decision  to  enter  the  era  of  in¬ 
formation  resource  management  —  infering,  of  course,  the  creation  and 
maintenance  of  a  corporate  database  which  is  designed  as  a  decision- 
support  tool  —  there  are  three  steps  which  should  be  taken  by  the  top 
management : 

a.  ESTABLISH  THE  IRM.  A  distinct  functional  element  should  be 

created  for  information  resource  management.  A  specific  person 
should  be  designated  as  the  Information  Resource  Manager.  A 
core  staff  of  at  least  four  or  five  analysts  should  be  assigned 
at  the  outset  to  take  part  in  the  requirements  study  (see 
below)  and  to  begin  to  build  the  staff's  technical  excellence. 
Additional  technical  people  will  be  needed  as  the  detailed 
plans  evolve. 


b.  DETERMINE  THE  HIGHEST  MANAGEMENT  LEVEL  TO  BE  SUPPORTED  BY  THE 
CORPORATE  DATABASE.  As  discussed  in  Section  3,  a  fundamental 
decision  must  be  made  about  the  highest  level  of  management 
which  the  corporate  database  will  be  designed  to  support: 

1.  Top-level  general  managers  (i.e.,  the  Commander,  Dep¬ 
uty  Commander,  Technical  Director,  Chief  of  Staff). 

2.  Functional  managers  (i.e.,  Directors,  Deputy 


Directors,  Office  Chiefs) 


3.  Operational  managers  (Division  and  Branch  Chiefs) • 
Based  on  our  reading  of  the  literature  cited  and  the  reality 
that  much  of  the  information  generated  within  AVRADCOM  is 
needed  in  order  to  respond  to  requests  from  higher 
"corporations,"  particularly  DARCOM  and  DA,  we  recommend  that 
the  corporate  database  be  designed  as  a  decision-support  system 
for  the  top-level  general  managers. 

ESTABLISH  A  TEAM  TO  DETERMINE  THE  INFORMATION  REQUIREMENTS  OF 
MANAGEMENT.  As  discussed  so  often  in  the  literature  and  re¬ 
viewed  in  Section  3  of  this  report,  the  important  answers  to 
the  question,  "What  Information  do  managers  need?,"  must  be 
found  before  the  detailed  specifications  of  the  corporate 
database  are  generated.  A  "requirements  team"  should  be  desig¬ 
nated  to  pursue  this  question.  It  should  follow  the  direction 
of  a  consultant  who  has  had  first-hand  experience.  The  in- 
house  members  of  the  team  should  include  at  least: 

1.  One  of  the  top-level  general  managers. 

2.  The  Information  Resource  Manager. 

3.  Two  analysts  from  the  staff  of  the  IRM. 

The  need  for  participation  of  a  top-level  manager  as  an  active 
member  of  this  team  is  clearly  stated  by  Martin  (Ref  36), 
McNurlln  (Ref  14),  and  other  writers  who  discuss  the  reasons 
why  typical  management  Information  systems  have  not  succeeded 
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as  aids  to  decision-making.  They  warn  of  the  many  probable 
pitfalls  in  entering  the  era  of  information  resource  management 
without  top-management  involvement  and  support. 

At  the  operational  level,  there  are  many  other  tasks  and  plans  to 
be  undertaken  by  the  IRM  (c.f..  Sections  5.2  and  5.3)  in  structuring 
work  assignments,  developing  training  plans,  establishing  policies  and 
procedures  for  data  access,  retrieval,  query,  etc.  These  do  not  require 
the  active  involvement  of  top  management  until  they  are  ready  for  review 
fis  corporate  policy. 

Since  the  IRM's  staff  will  be  the  source  of  in-depth  technical 
knowledge  of  Data  Base  Management  Systems  for  the  whole  corporation 
(c.f..  Section  4.4),  it  should  begin  with  the  design  and  implementation 
of  the  Data  Dictionary /Directory  (Section  4.1)  and  one  or  more  rela¬ 
tively  small  database  projects  in  order  to  develop  the  necessary  techni¬ 
cal  experience.  These  seed  projects  do  not  require  the  active  involve¬ 
ment  of  top  management  except,  of  course,  for  the  commitment  of  person¬ 
nel  to  the  staff. 

The  amount  of  ground  work  which  can  be  done  while  the  requirements 
team  is  working  depends  on  the  speed  with  which  the  IRM's  staff  can  be 
recruited . 

The  scope,  complexity,  and  the  specifications  of  the  corporate 
database  itself  cannot  be  reasonably  anticipated  until  the  requirements 
study  is  complete.  At  that  time  the  IRM  should  present  a  clear  set  of 
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functional  requirements  for  a  top-level  management  review  and  decision. 
Following  an  agreement  (by  all  accounts,  no  trivial  matter!)  about  the 


intended  functions  of  the  corporate  database,  the  "master  plan"  should 
be  developed.  This  will  include  specifications  and  a  timetable  based  on 
expectations  for  the  staff's  growth  and  training.  It  is  reasonable  to 
assume  we  will  follow  the  overall  recommendations  of  others  to  "plan 
big,"  for  the  long  term,  but  to  implement  carefully  with  a  series  of 
small,  well-designed  projects. 
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1.  An  information  control  system  is  not  a  large,  complex,  super- 
sophisticated  information  filing  system.  It  is  a  tool  for  making  deci¬ 
sions  in  the  highly  complex,  probabilistic  business  environment  (Ref  I, 
page  85). 

2.  Application  systems  are  not  control  systems;  they  are  filing  systems 
(Ref  1,  page  85). 

3.  One  thing  is  for  sure;  the  most  dynamic  need  in  business  is  the  need 
for  information  (Ref  1,  page  86). 

4.  The  alternative  to  the  applications  systems  approach  is  the  data  base 
approach  (Ref  1,  page  86). 

5.  [The  data  base  approach]  requires  a  complete  psychological 
reorientation  to  computerization,  not  just  for  management,  but  for  data 
processing  folks  as  well  (Ref  I,  page  86). 

6.  ..."data  base"  does  not  refer  to  the  physical  structure  of  computer 
files  (Ref  1,  page  87). 

7.  Data  bases  do  not  store  Information  as  information.  They  store  data 
which  can  be  used  to  generate  information  (Ref  1,  page  87). 

8.  ...the  ground  rules  [for  data  base  management]  require  that  the  concept 
of  individual  computer  applications,  each  with  its  own  input,  storage 
and  output,  be  abandoned  (Ref  I,  page  87). 

9.  [ DBMSs ]... have  as  their  primary  purpose  the  maintenance  of  data  quality 
and  integrity.  They  are  not  concerned  with  the  ultimate  use  of  the 
data  (Ref  1,  page  87). 

10.  Management's  information  needs  rest  on  only  400-800  elements  of  data 
(Ref  1,  page  87). 

11.  Data  base  development  is  performed  in  a  data  base  management  environ¬ 
ment  organized  around  three  basic  control  systems:  1)  a  data  base 
input  control  system,  2)  a  data  base  output  control  system,  and  3)  a 
data  base  storage  and  processing  control  system  (Ref  1,  page  87). 

12.  The  processing  and  control  system  is  an  independent  data  base  manage¬ 
ment  system  with  built-in  capabilities  for  controlling  backup,  recov¬ 
ery,  data  availability,  security,  computer  efficiency,  and  so  on.  It 
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is  generally  controlled  by  an  Individual  called  a  Data  Base  Adminis¬ 
trator  (Ref  I,  page  87). 

13.  A  conventional  data  processing  department  performs  a  basically  cleri¬ 
cal  role  in  spport  of  many  individual  computer  applications  while 
under  the  [data  base]  environment  it  must  have  a  company-wide  respon¬ 
sibility  for  managing  data  base  input,  data  base  output,  and  data  base 
storage  and  processing  activities. . .Rarely  will  the  technologies  in¬ 
volved  be  the  same,  nor  will  there  be  compatibility  in  the  overall 
skills  or  Internal  controls  required  within  the  departments  (Ref  1, 
page  90). 

14.  [A  management  information]  department  functioning  in  a  data  base  sys¬ 
tems  environment  must  play  an  active,  supportive  role  in  determlng  how 
a  company  can  be  most  productively  managed.  Regular  data  processing 
departments  are  rarely  staffed  to  perform  this  role,  nor  are  they 
looked  to  for  management  guidance. .. [They ]  cannot  function  effectively 
in  the  environment  which  data  base  management  creates,  nor  can  they  be 
called  upon  by  management  to  develop  that  environment.  The  skills  and 
basic  understanding  just  do  not  exist  (Ref  1,  page  90). 

15.  The  political,  economic,  business,  management  and  computer  skills 
needed  to  successfully  and  properly  construct  a  data  base  rarely  exist 
in  a  conventional  data  processing  department  (Ref  1,  page  92). 

16.  ...management  must  back  up  its  intent  [to  utilize  data  base  manage¬ 
ment]  by  establishing  the  authority  and  responsibility,  both  func¬ 
tional  and  financial,  needed  by  the  [new]  department  to  establish  and 
manage  a  data  base  systems  environment  (Ref  1,  page  92). 

17.  A  company  which  Intends  to  develop  an  efficient  and  cost-effective 
data  base  environment  must  be  prepared  to  adopt  and  implement  the  fol¬ 
lowing  general  guidelines  (Ref  1,  page  92): 

1.  The  data  base  must  be  built  for  the  whole  company,  not  for  in¬ 
dividual  managers. 

2.  Data  base  development  must  follow  a  logical,  well  orchestrated 
plan,  not  the  path  of  least  resistance. 

3.  Data  processing  must  be  Intended  to  improve  overall  productiv¬ 
ity  by  supplying  accurate  information  based  on  management 
needs,  not  justified  through  cost  reductions  based  on  personnel 
replacement. 

4.  Management  must  concentrate  primarily  on  identifying  the  infor¬ 
mation  it  needs  to  manage. 
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5.  MIS  muse  control  what  Is  stored  on  the  computer  and  how 


6.  Company  input  responsibilities  should  be  established  and  funded 
separate  from  output  needs. 

7.  MIS  must  be  given  increased  responsibility  for  input  control 
and  data  integrity  and  accordingly,  authority  for  defining  and 
obtaining  required  input. 

8.  Investments  in  hardware,  software  and  personnel  must  be  based 
on  the  needs  of  the  data  base  control  systems,  not  on  require¬ 
ments  for  specific  applications. 

18.  Data  base  is  the  future.  Any  company  which  intends  to  grow  and 
prosper  must,  sometime  during  the  next  5-10  years,  move  away  from  ap¬ 
plication  systems  toward  data  base  systems.  To  do  so  it  will  have  to 
commit  itself  financially  and  functionally  to  a  path  of  migration  to 
data  base.  This  will  be  a  major  commitment,  not  to  be  taken  lightly. 
It  will  require  a  whole  new  philosophy  about  what  role  computers,  sys¬ 
tems,  and  data  processing  personnel  really  play  in  company  management. 
But  more  than  anything  else,  it  will  require  a  positive  and  aggressive 
program  to  change  attitudes  and  ideas  in  both  functional  and  data  pro¬ 
cessing  management  (Ref  1,  page  92). 

19.  There  are  hardly  any  technical  problems  involved  with  installing  a 
DBMS,  only  people  problems  and  managerial  ones  (Ref  2,  page  3). 

20.  ...the  company  selected  a  systems  programmer  who  "could  be 
spared". . .Not  only  was  this  choice  of  the  key  person  poor  but  so  was 
the  choice  of  the  first  application. . .This  experience  convinced  user 
departments. . .that  a  DBMS  was  inefficient  and  just  another  programming 
fad  (Ref  2,  page  3). 

21.  Don't  start  the  wrong  way  [to  shift  to  a  DBMS]  or  it  could  take  you 
ten  years  or  an  organizational  crisis  to  change  and  do  it  right  (Ref 
2,  page  4). 

22.  ...a  DBMS  will  cause  important  shifts  in  responsibilities  (Ref  2,  page 
4). 

23.  First,  a  reasonably  high  level  of  top  management  acceptance  and  sup¬ 
port  is  needed. • .Second ,  use  competent  managers,  to  provide  good  man¬ 
agement  control  of  the  DBMS  project.  Third,  assign  competent  techni¬ 
cians,  Including  a  data  administration  staff,  with  proper  tools.  And 
finally  get  competent  auditors  to  monitor  content,  security,  and  pri¬ 
vacy  of  the  entire  data  base  system  (Ref  2,  page  4). 
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[The  chairman  of  Che  CODASYL  Systems  Committee]  recommended  that  a 
data  dictionary  be  installed  before  the  first  data  base  application  is 
fully  operational  (Ref  2,  page  4). 

Some. . .organizations  have  a  percentage  of  their  applications  running 
under  one  or  more  DBMS,  but  with  little  or  no  sharing  of  data  among 
the  applications.  "Data  bases"  in  these  organizations  are  much  the 
same  as  application  files,  and  the  DBMS  is  used  as  just  a  fancy  new 
access  method  (Ref  2,  page  4). 

Here  are  the  elements  that  make  up  the  total  data  base  environment 
(Ref  2,  page  5): 

Data  definitions. 

Data  files. 

DBMS. 

Computer  programs. 

Data  dictionary. 

Query  and  report  writing  facilities. 

Data  administrator  function. 

Security  and  integrity  functions. 

Many  users  of  data  base  technology  have  come  to  realize  that  they 
should  have  Installed  a  mechanized  data  dictionary,  to  get  their  data 
definitions  under  control,  before  they  installed  a  DBMS  (Ref  2,  page 
5). 

...users  of  data  base  technology  have  learned. . .that  they  should  have 
set  up  the  data  administration  function  even  before  they  installed  a 
data  dictionary,  and  have  both  installed  prior  to  the  installation  of 
the  DBMS  (Ref  2,  page  5). 

...converting  to  data  base  technology  is  no  simple  matter  (Ref  2,  page 
5). 

The  broad  question  of  data  management  lies  at  the  very  center  of  the 
organization  management  process... So  in  dealing  with  the  data  of  the 
organization,  one  deals  with  the  heart  and  soul  of  management  (Ref  2, 
page  6). 


31.  It  Is  essential  that  management  establish  DBMS  objectives  (Ref  2,  page 

6). 

32.  An  unequivocal  statement  of  responsibility  and  a  proper  structure  must 
be  provided  for  the  data  management  function. . .The  new  organization 
should  include  strong,  central,  total  authority  over  data  definitions 
and  related  DBMS  functions  (Ref  2,  page  6). 

33.  Insufficient  training  for  computer  professionals  seems  to  center  on 
the  areas  of  decision  theory,  systems,  and  man-machine  dialog... But 
the  greatest  need  is  for  management  training  in  information  systems  in 
general  and  data  base  management  systems  in  particular  (Ref  2,  page 
7). 

34.  [Converting  to  a  DBMS]  is  primarily  a  management  problem,  for  both  ex¬ 
ecutive  management  and  data  processing  management  (Ref  2,  page  7). 

35.  Management  should  recognize  that  the  problem  of  converting  to  data 
base  technology  is  not  one  that  will  just  "go  away"  if  it  is  ignored 
long  enough.  It  is  a  question  of  when,  not  whether  (Ref  2,  page  7). 

36.  The  first  DBMS  that  an  organization  installs  will  be  just  that  —  the 
first  of  many  (Ref  2,  page  8). 

37.  The  [Data  Base  Directions  Panel]  strongly  urged  that  the  good  practice 
be  followed  of  installing  a  data  dictionary  and  getting  the  data  defi¬ 
nitions  under  control  before  installing  a  DBMS  (Ref  2,  page  11). 

38.  Companies  that  use  data  base  systems  have  in  essence  recognized  that 
data  represent  a  major  corporate  resource.  Thus  they  have  taken  three 
steps  in  order  to  standardize  the  processng  of  data  throughout  the 
coporatlon  (Ref  3,  page  131): 

1.  Establish  a  data  base  administrative  function. .. [over]  all  cor¬ 
porate  data. 

2.  Develop  structured  data  bases  to  replace  the  individual  files. 

3.  Install  the  set  of  computer  programs  required  to  create  and  ma¬ 
nipulate  the  data  bases. 

39.  One  of  the  most  important  elements  in  planning  for  a  data  base  system 
is  an  analysis  at  the  outset  of  potential  costs  and  benef its. . . It  be¬ 
comes  a  focal  point  for  management  involvement  at  all  levels,  which  is 
indispensable  to  any  data  base  development  efforts. .. (Ref  3,  page 
132). 


40.  Possibly  the  greatest  payoff  could  come  in  this  area  [of  general  man¬ 
agement]  (Ref  3,  page  135). 

41.  With  a  data  base... a  high  degree  of  independence  is  possible  between 
application  programs  and  the  data  base... The  productivity  of  analysts 
and  programmers  often  doubles,  or  even  triples,  once  they  become  thor¬ 
oughly  familiar  with  the  DBMS  (Ref  3,  page  137). 

42.  Tomorrow's  information  services  executive  will  have  at  least  four 
roles,  some  of  them  quite  new.  He  or  she  will  be  the  architect  and 
information  services  planner,  the  information  broker,  the  auditor  who 
measures  the  quality  of  the  service  delivered  and  assures  the  integ¬ 
rity  of  the  information  system,  and  finally,  the  operator  of  those 
systems  that  continue  to  be  centralized. . .The  information  services  ex¬ 
ecutive  will  become  much  more  a  corporate  staff  member. ..His  or  her 
decision  at  this  level  will  affect  the  way  an  organization  can  be 
structured  and  the  efficiency  with  which  it  can  operate  (Ref  5,  page 
146). 

43.  ...there  will  arise  an  information  services  executive  of  power  and 
stature  similar  to  that  of  the  comptroller.  The  rank  will  be  that  of 
vice  president  and  the  information  he  or  she  controls  will  be  viewed 
as  one  of  the  organization's  most  valuable  resouces. . .The  current  MIS 
practloner  may  or  may  not  be  that  person.  Success  will  come  to  the 
one  who  starts  now  to  conceptualize  tomorrow's  role  for  information 
processing  and  its  manager  (Ref  5,  page  151). 

44.  ...the  Data  Administrator's  function  requires. . .characteristics  which 
are  not  all  readily  found  In  any  one  individual  (Ref  6,  page  7 
(quoting  the  EDP  Analyzer  of  November  1972)): 

1.  Two  to  five  years  experience  as  a  systems  designer  and  program¬ 
mer  with  some  of  this  exprience  in  large-scale  integrated  sys¬ 
tems. 

2.  Experience  in  large  data  base  design. 

3.  Ability  to  lead,  organize,  and  control. 

4.  Knowledge  of  user  requirements. 

5.  General  technical  and  communicative  skills. 

6.  Diplomat  extraordinare. 

45.  The  Data  Administrator  is  defined  as  that  individual  or  group  respon¬ 
sible  for  the  design,  creation,  integrity,  efficiency,  and  administra- 
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Cive  functions  of  a  multi-user  data  base  [i.e.  updates  from  more  than 
one  functional  area]... If  a  multi-user  data  base  is  used  or  is 
contemplated,. . .a  Data  Administrator  is  a  necessity  and  not  just  a 
luxury  (Ref  6,  page  10). 

46.  The  data  base  design  function  is  involved  with  data  elements,  data  use 
identifiers  [DE/DUI],  data  dictionary/directory  [DD/D],  and  data  and 
storage  structures  (Ref  6,  page  11). 

47.  The  Data  Administrator  is  responsible  for  acquiring  or  building  this 
DD/D  and  for  deciding  what  information  about  the  DE/DUIs  should  be  in¬ 
cluded  (Ref  6,  page  11). 

48.  The  Data  Administrator  has  sole  responsibility  for  this  function  [of 
data  base  creation]  (Ref  6,  page  12). 

49.  The  efficiency  of  the  data  base  is  the  sole  responsibility  of  the  Data 
Administrator  (Ref  6,  page  14). 

50.  Data  base  design  is  perhaps  the  most  critical  Data  Administration 
function. .. [His]  ability  to  translate  user  requirements  into  an  effec¬ 
tive  DD/D,  data  structure,  and  storage  structure  will  be  the  final 
measure  of  how  well  he  performs  this  design  function  (Ref  6,  page  23). 

51.  The  DD/D  is  maintained  by  the  Data  Administrator. .. (Ref  6,  page  24). 

52.  ...many  organizations  that  have  tried  to  do  without  the  position  [of 
data  base  administrator]  have  found  they  could  ill  afford  to  continue 
without  it  (Ref  7,  page  123). 

53.  The  major  areas  of  responsibility  in  data  base  administration  are  (1) 
data  base  description;  (2)  control  of  data  access;  (3)  system  support, 
protection,  and  tuning;  and  (4)  information  enhancement  (Ref  7,  page 
123). 

54.  Control  of  the  data  dictionary  is  in  all  cases  the  responsibility  of 
the  [data  base  administrator]  (Ref  7,  page  128). 

55.  This  role  [of  data  base  administration]  requires  familiarity  with  sev¬ 
eral  levels  of  organizational  activity:  (1)  management  planning,  pol¬ 
icies,  and  goals;  (2)  application  design  and  development;  and  (3) 
inter-area  use  of  system  resources. .. [the]  position  of  DBA  is  central¬ 
ized,  with  sufficient  authority  to  obtain  that  information  and  compli¬ 
ance  necessary  for  designing  and  supporting  an  effective  data  base 
system.  The  DBA  should  not,  however,  be  a  member  of  a  central  systems 
support  group  (Ref  7,  page  130). 
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56.  Concentration  of  DBMS  knowledge  within  a  central  DBA  group  produces 
the  best  results  in  terms  of  the. . .prof iciency  that  can  be  achieved 
and  eliminates  wasteful  redundancy ...  In  short,  a  central  DBA  team  is 
the  best  solution  for  in-house  DBMS  support  (Ref  7,  page  131). 

57.  Organizations  using  DBMS  find  themselves  in  one  of  three  situations: 
transition,  expansion,  or  corporate  (Ref  7,  page  132). 

58.  A  fully  empowered  data  base  administration  team  becomes  necessary  for 
most  organizations  [which  integrate  data  into  corporate  data  bases]. 
This  team  not  only  oversees  data  base  activities  but  coordinates  and 
controls  much  of  the  information  flow  within  the  organization  (Ref  7, 
page  132). 

59.  ...an  initial  period  of  adjustment  and  trial  and  error  is  important 
for  the  eventual  success  of  the  data  base  support  project.  A 
transition  period  allows  a  relatively  painless  shaping  of  data  base 
administration  tasks  to  occur  (Ref  7,  page  134). 

60.  The  ideal  time  for  establishing  a  DBA  position  is  during  the 
transition  stage,  well  before  data  base  systems  become  critical  to  or¬ 
ganizational  production  (Ref  7,  page  134). 

61.  The  ideal  candidate  [for  the  data  base  administrator]  is  a  person 
equally  comfortable  with  the  roles  of  technician,  administrator,  and 
diplomat.  The  selection  of  a  qualified  DBA  is  in  fact  one  of  the  most 
crucial  steps  in  establishing  successful  data  base  projects  (Ref  7, 
page  135). 

62.  Without  strong  senior  management  support  and  Database  Administration, 
the  Database  effort  will  result  in  only  minimum  benefits  to  the  orga¬ 
nization  (Ref  8,  page  42). 

63.  ...two  separate  positions  (offices)  may  be  required  with  two  different 
functional  requirements.  One  might  be  called  the  Data  Administrator 
and  the  other  the  Data  Base  Administrator.  The  Data  Administrator 
manages  the  Database  Administration  section,  is  on  the  corporate 
staff,  and  is  responsible  for  coordinating  data  collection,  storage, 
and  dissemination  efforts  throughtout  the  company... A  Data  Base  Admin¬ 
istration  group  should  also  be  established,  reporting  to  the  Director 
of  Data  Processing.  [This  group  is]  managed  by  a  Data  Base  Adminis¬ 
trator  responsible  for  managing  the  Data  Bases  and  the  use  of  the 
DBMS. . .He/she  is  also  responsible  for  implementing  the  directives  and 
policies  of  the  Data  Administrator ... (Ref  8.  page  42). 

64.  Each  set  of  data  is  stored  as  a  data  base... under  the  control  of  one 
person  or  Local  Data  Administrator  (LDA)...The  concept  is  to  delegate 
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and  decentralize  data  administration  among  LDAs... while  concurrently 
maintaining  overall  data  administration. . .by  a  Global  Data  Administra¬ 
tor  (GDA)...It8  overall  concept  is  to  place  data  management  capabili¬ 
ties  directly  into  the  hands  of  the  user  of  data  (Ref  9,  page  6). 

65.  Before  a  Data  Administration  function  can  be  established,  certain  con¬ 
ditions  must  exist: 

(a)  Top  management  must  be  willing  to  take  a  long-range  view  of 
the  cost  structure. 

(b)  DP  and  line  management  must  be  prepared  for  the  data  base  ap¬ 
proach  with  the  associated  protocols,  standards,  etc;  and 

(c)  The  entire  line  management  must  view  data  as  a  resource  simi¬ 
lar  to  raw  materials,  equipment,  etc.  (Ref  10,  page  43). 

66.  ...a  formal  structure  [for  data  administration]  is  needed  which  may  or 
may  not  be  within  the  data  processing  organization  (Ref  10,  page  43). 

67.  Information  needs  to  be  treated  as  an  organizational  resource  (Ref  11, 
page  69). 

68.  Serving  as  the  principal  advisor  to  top  and  middle  federal  managers, 
the  so-called  information  manager,  according  to  the  draft  proposal, 
would  provide  technical  expertise  and  counsel  on  such  matters  as  in¬ 
formation  plans,  budgets,  and  security  measures. . .acting  as  a  bridge 
between  increasingly  costly,  complex  and  diversified  information  han¬ 
dling  technologies  on  the  one  hand,  and  larger  and  larger  numbers  of 
managers  and  users  unfamiliar  with  the  technologies,  their  applica¬ 
tions,  their  costs,  and  their  values. .. (Ref  11,  page  70). 

69.  [The  commissioner  of  GSA's]  Automated  Data  &  Telecommunications  Ser¬ 
vice  feels  strongly  that  expertise  in  the  computer  and  telecommunica¬ 
tions  fields  would  be  a  qualifying  must  for  the  proposed  information 
manager  position  (Ref  11,  page  73). 

70.  The  data  base  is  forcing  more  awareness  of  data  as  a  corporate  re¬ 
source.  Because  data  in  a  data  base  is  used  by  all  authorized  depart¬ 
ments,  it  has  become  clear  that  the  definition  of  the  data  cannot  be 
left  to  individual  departments  (Ref  13,  page  6). 

71.  ...the  function  of  the  data  administrator  (or  data  base  administrator) 
has  emerged  to  exert  control  over  data  and  data  definitions  (Ref  13, 
page  6). 

72.  The  overall  function  of  data  administration  was  divided  into  three 
components  by  the  [ANSI/SPARC  data  base]  study  group,  primarily  to 
support  data  independence.  The  "enterprise  administrator"  is  a 
business-oriented  individual,  perhaps  on  the  staff  of  the  executive 
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vice  president. . .The  "application  system  administrator”  ...devel¬ 
ops...  the  data  definitions  and  relationship  definitions  as  seen  by  the 
application  programmers. .. [The]  "data  base  administrator"  creates  the 
"internal  data  base  plan"  defining  the  way  data  is  stored  in  the  data 
base  to  achieve  performance  and  economy  objectives  (Ref  13,  page  9). 

73.  ...both  of  the  companies  [studied  by  the  writers  of  Ref  14]... found  it 
necessary  to  create  new  management  positions  following  their  [determi¬ 
nation  of  the  information  needs  of  their  managers].  These  new  infor¬ 
mation  planning  executives  have  the  job  of  aligning  their  company's 
information  systems  with  the  management  information  needs... In  both 
cases  the  position  was  set  up  outside  of  the  data  processing  depart¬ 
ment,  either  just  above  it  or  along  side  of  it  organizationally  (Ref 
14,  page  11). 

74.  Information  Resource  Management  is  responsible  for. . .defining  and 
planning  all  new  uses  of  data  within  the  organization  and  for  ensuring 
that  these  uses  correspond  to  the  corporate  information  perspective 
(Ref  15,  page  13). 

75.  Information  must  be  classified  and  managed  as  a  corporate  resource  in 
spite  of  the  fact  that  it  is  inherently  intangible  (Ref  15,  page  17). 

76.  The  role  and  the  responsibilities  of  Information  Resource  Management 
n^ust  be  clear  and  placed  high  enough  within  the  organization  to  affect 
change  (Ref  15,  page  17). 

77.  Data  Base  Administration  is  an  integral  part  of  the  organization's 
commitment  to  meet  its  information  needs  by  the  data  base  approach  and 
to  use  its  DBMS  effectively  (Ref  15,  page  20). 

78.  Establishing  Data  Base  Administration  requires  extensive  knowledge  of 
the  organization  and  insight  into  its  objectives  and  functioning.  An¬ 
other  important  ingredient  is  the  ability  to  stand  back  and  objec¬ 
tively  appraise  the  organization's  procedures  and  personnel  (Ref  15, 
page  27). 

79.  Data  Base  Administration  is  an  agent  of  change,  "/his  charter  for 
change  requires  detailed  planning,  careful  preparation,  and  consider¬ 
able  resourcefulness.  Teamwork  and  cooperation  are  more  than  impor¬ 
tant  —  they  are  essential  (Ref  15,  page  27). 

80.  Information  Resouce  Management  helps  to  determine  an  organization's 
information  needs.  Data  Base  Administration  facilitates  the  produc¬ 
tion  of  information  the  organizaton  uses... (Ref  15,  page  28). 
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81.  Information  resource  management  is  concerned  with  the  knowledge  and 
management  of  the  composition,  description,  acquisition,  dissemina¬ 
tion,  and  flow  of  data  or  information  where  the  information  is  held  to 
be  a  resource  of  the  entire  organization  (Ref  16,  page  7). 

82.  There  is  no  single  source  of  information  policy  in  HQDA,  today  (Ref 

16,  page  8). 

83.  Data  Base  Administration  (DBA)  is  concerned  with  the  technical  design 
and  maintenance  of  data  bases  used  in  information  systems.  Data  Base 
Administration  is  a  highly  technical  area  which  requires  significant 
technical  training  (Ref  16,  page  9). 

84.  ...we  conceive  the  management  of  the  data  resource  to  be  parallel  to 
the  management  of  the  manpower,  money,  machinery  and  material  re¬ 
sources.  It  is  a  staff  activity,  apart  from  such  support  services  as 
records  operations  or  data  processing  (Ref  17,  page  140). 

83.  Among  the  key  requirements  for  effective  database  administration  are: 
strong  management  commitment  and  support;  technically  competent  staff; 
team  participation  in  the  database  environment  by  DBA's,  management, 
technical  staff,  and  users;  and  a  well-defined  Database  Master  Plan 
(Ref  19,  page  3). 

86.  It  is  [the  DBA's]  responsibility  to  maintain  and  update  database  defi¬ 
nitions  and  databse  documentation,  and  to  maintain  and  update  the 
[Data  Element  Dictionary/Directory]  and  other  database  support  soft¬ 
ware.  The  DBA  should  interpert  and  administer  high  level  management 
policies  related  to  the  database,  and  define  rules  of  use  and  access 
constraints  for  the  database  (Ref  19,  page  5). 

87.  The  consensus  among  data  resource  technologists  is  that  the  DBA  func¬ 
tion  should  be  placed  very  high  organizationally  in  order  to  ensure 
its  success  (Ref  19,  page  7). 

88.  Three  examples  of  organizational  placement  are  presented  below  (Ref 
19,  page  7): 


...the  DBA  is  located  in  the  director's  off ice. .. [where  he] 
should  have  access  to  the  organizational  data  resources  and  can  exact 
cooperation  from  the  line  organizations. 

...the  DBA  [is  located]  as  a  staff  position  in  the  Comptrol¬ 
ler's  Of f ice. .. [where ]  the  "purse  string"  can  be  used  as  a  lever  in 
assuring  compliance  to  database  rules  and  regulations. 

...the  DBA  [is  located]  as  a  sub-unit  of  the  data  processing 


A-12 


shop.  This  represents  the  lower  end  of  the  spectrum  in  organizational 
placement.  [Here]  the  DBA  usually  would  have  less  authority 
organization-wide .. .and  can  expect  less  cooperation  from  the  rest  of 
the  organization. 

89.  The  date  of  creation  of  the  [database  administration]  function  fre¬ 
quently  was  preceded  by  extensive  unofficial  initiation  activities, 
ranging  from  12  to  18  months  (Ref  19,  page  15). 

90.  [Of  the  twelve  federal  agencies  surveyed  by  the  NBS,  those  which  have 
an  operational  database  administration  activity  state  that  it]  is  usu¬ 
ally  located  within  the  data  processing/information  management  area  of 
an  organization;  it  is  most  often  separate  from,  but  on  a  par  with, 
the  computer  operations  activity.  Sometimes,  there  is  a  tie  to  the 
comptroller's  office,  or  to  the  office  of  the  director  for  administra¬ 
tion  (Ref  19,  page  16). 

91.  [The  NBS  survey  of  federal  database  administrators]  identified  several 
specific  [non-technical ]  problems  (Ref  19,  page  25): 

1.  Lack  of  commitment  to  database  administration  concepts  at  dif¬ 
ferent  management  levels; 

2.  Management  hesitant  to  commit  manpower  and  money  to  internally- 
oriented,  non-visible  projects; 

3.  Unreasonable  management  demands; 

4.  Lack  of  decision-making  power  for  the  DBA; 

5.  Lack  of  enforcement  power  for  the  DBA; 

6.  Unresolved  jurisdictional  problems,  especially  when  different 
groups  perform  database  administration  tasks; 

7.  Unclear  definition  of  responsibilities  of  DBA's,  analysts, 
users,  and  management; 

8.  Frequent  reorganization  causing  instability  in  control  of  data; 

9.  Undefined  ownership  and  control  of  data,  especially  between 
users  and  DBA; 

10.  DBA  concepts  conflict  with  service  center  concepts; 

11.  Failure  to  establish  effective  communication  lines  between 
DBA's,  technical  staff,  and  management; 
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12.  Insufficient  communication  between  DBA's  and  users  with  re¬ 
spect  to  data  errors  and  availability  of  help; 

13.  Decision-making  management  not  knowledgeable  in  technological 
state-of-the-art ; 

14.  Lack  of  training  and  understanding  of  database  concepts  and 
DBMS  by  users  and  technical  staff; 

15.  Lack  of  experience  in  database  technology; 

16.  Skepticism  with  respect  to  the  success  of  database  administra¬ 
tion  practices; 

17.  Resistance  of  analysts  and  programmers  to  DBA  interference; 

18.  Excessive  procurement  constraints  on  purchase  of  hardware, 
software,  and  services; 

19.  Inadequate  cost-benefit  analyses  regarding  implementing  DBMS 
vs.  conventional  programming,  and  in  evaluating  in-house  vs. 
commercial  software; 

20.  High  cost  of  hardware,  software,  services,  technical  staff, 
training,  and  vendor  support. 

92.  The  following  advice  was  offered  by  the  practicing  DBA's  to  those 

about  to  establish  this  function.  ...[It]  should  be  helpful  to  future 
DBA's  since  it  is  based  on  actual  experience  (Ref  19,  page  27): 

1.  Get  complete  management  support,  and  get  it  early; 

2.  Establish  a  strong  organization,  with  good  lines  of  communica¬ 
tion; 

3.  Have  a  good  Database  Master  Plan; 

4.  Be  flexible,  and  adaptable  to  change; 

5.  Develop  credibility; 

6.  Be  a  combination  of  a  good  technician  and  a  good  politician; 

7.  Involve  the  users  in  planning; 

8.  Hire  staff  with  strong  database  technology  background,  and  sys¬ 
tem  software  experience. 
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9.  Develop  strong  training  program  for  staff,  users  and  manage¬ 
ment  ; 

10.  Agree  on  standards  first  before  designing  a  system; 

11.  Design  a  total  system,  but  implement  it  in  segments; 

12.  Experiment  with  different  approaches; 

13.  Implement  a  DED/D  early; 

14.  Consider  the  usage  of  a  DBMS  early; 

15.  Do  benchmarks  when  possible; 

16.  Don't  try  to  do  too  much  at  once; 

17.  Be  patient.  It  may  be  a  long  time  before  you  see  results. 

93.  The  MIS  role  will  be  increasingly  one  of  "data  base  administrator," 
maintaining  definitions  of  standard  data  elements  and  getting  users  to 
agree  on  who  is  responsible  for  maintaining  which  data  elements  (Ref 
21,  para  E2c). 

94.  The  implementation  of  a  DBMS  can  be  complex,  time  consuming,  and 
costly,  and  i*  can  affect  every  information  handling  aspect  of  an 
organization. .. [Successful]  implementation  requires  careful  planning 
(Ref  23,  page  10). 

95.  [The  method  developed  by  MIT  to  determine  the  informaton  needs  of  man¬ 
agers]  takes  into  consideration  the  fact  that  information  needs  will 
vary  from  manager  to  manager  and  that  these  needs  will  change  with 
time  for  a  particular  manager  (Ref  24,  page  85). 

96.  There  are  significant  benefits  of  taking  the  necessary  time  to  think 
through  —  and  to  record  —  the  critical  success  factors  for  each  gen¬ 
eral  manager  in  an  organization. . .The  informaton  system  [designed 
around  the  manager's  critical  success  factors]  should  be  in  constant 
flux. ..to  accomodate  changes. . .Rather  than  changes  in  an  information 
system  being  looked  on  as  an  indication  of  "inadequate  design,"  they 
must  be  viewed  as  an  inevitable  and  productive  part  of  information 
systems  development  (Ref  24,  page  88). 

97.  In  these  areas  [of  expertise  required  for  use  of  data  base  technol¬ 
ogy].  skills  of  the  highest  possible  caliber  are  absolutely  essential 
for  a  successful  data  base  system  project  (Ref  27,  page  8). 
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98.  DBMS  is  a  new  technology  and  even  people  whom  you  think  are  superior 
technologists  will  have  to  be  retrained  (Ref  28,  page  S/13). 

99.  "Data  base  administrator”  (DBA)  is  not  a  fancy  name  for  a  systems  pro¬ 
grammer.  The  DBA  is  a  unique  specialty  which  requires  more  DP  manage¬ 
ment  and  user  application  skills  than  systems  programming  know-how. 

The  DBA  must  be  fully  indoctrinated  into  the  concepts  of  data  resource 
management  (Ref  28,  page  S/13). 

100.  [The  Standards  Working  Panel  at  a  recent  NBS  and  ACM  workshop]  called 
for  the  establishment  of  a  group  dedicated  to  the  management  of  an 
organization's  data. ..[The  panel]  felt  data  should  be  managed  as  a 
corporate  resource. .. (Ref  29,  page  S/14). 

101.  The  data  base  administrator  was  regarded  [by  the  panel]  as  one  job 
description  in  the  data  management  function.  ...[The]  data  base  ad¬ 
ministrator  should  have  "primary  responsibility  for  the  overall  accu¬ 
racy,  timeliness  and  availability  of  the  corporate  data  through  di¬ 
rect  control  over  the  data  dictionary /directory  system"  (Ref  29,  page 
S/14). 

102.  Executive  management  must  take  an  active  role  in  the  evaluation  and 
lmplementaton  of  a  Data  Base  Management  System  (DBMS)... It  is  a  deci¬ 
sion  that  cannot  be  made  casually  or  by  lower  levels  of  management 
(Ref  32,  page  S/3). 

103.  If  set  up  properly,  a  data  base  can  become  the  hub  of  an  executive 
declson-support  system  by  readily  answering  the  what-if  questions  and 
facilitating  ad  hoc  reporting  (Ref  32,  page  S/3). 

104.  The  appointment  of  a  DBA  is  essential  because  a  DBMS  requires  the 
complete  attention  of  one  individual  or  group.  It  is  essential  that 
careful  control  of  the  analysts,  planning  and  lmplementaton  of  a  data 
base  be  handled  on  a  day-to-day  basis  under  one  roof  (Ref  32,  page 
S/12). 

105.  The  information  specialist  does  need  to  have  a  good  understanding  of 
the  uses  that  will  be  made  of  the  information  that  flows  through 
[the]  systm  (Ref  33,  page  95). 

106.  The  information  specialist  has  to  resist  the  temptation  to  alter  the 
specifications  of  the  Information  so  as  to  facilitate  data  processing 
or  to  make  them  fit  his  own  conception  of  what  data  should  be  sup¬ 
plied  to  management  (Ref  33,  page  96). 

107.  ...it  is  not  [the  responsibility  of  the  information  specialist]  to 
decide  what  information  the  manager  should  have,  it  is  his  responsi- 
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bility  to  show  the  manager  what  information  he  can  have  (Ref  33,  page 
97). 

108.  The  DBA  is  responsible  for  the  creation  and  maintenance  of  the  Data 
Base  Directory  (Ref  34,  page  8). 

109.  An  important  function  of  the  DBA  is  the  recording  of  procedures, 
standards,  guidelines,  and  data  base  descriptions  necessary  for  the 
proper,  efficient,  and  continuing  utilization  of  the  data  base  (Ref 
34,  page  23). 

110.  If  the  DBA  is  unable  to  gain  management's  support  and  approval  of  his 
goals  and  objectives  in  managing  the  DBMS,  then  he  will  not  be  able 
to  fully  exploit  the  corporate  data  resource.  Similarly,  the  DBA 
must  be  kept  apprised  of  management’s  policies,  goals, .and  objectives 
(Ref  34,  page  45). 

111.  First,  a  data  base,  or  data-base  management  system,  does  not  imply  a 
"management  information  system."  There  is  no  direct  relationship  be¬ 
tween  the  terms  (Ref  36,  page  231). 

112.  A  second  delusion  is  that  a  data-base  system  is  sometimes  described 
as  containing  all  the  data  items  in  a  corporation  or  a  division... 

Any  attempt  to  implement  so  grand  a  notion  is  doomed  to  disaster  be¬ 
fore  it  begins  (Ref  36,  page  231). 

113.  [Another]  delusion  is  the  notion  that  an  organization  will  have  one 
data  base.  In  reality  it  is  likely  to  have  many  databases. .. [M]ost 
corporations  should  not  talk  about  a  corporate-wide  data  base  but 
rather  a  corporate-wide  organizing  principle  which  forms  the  struc¬ 
ture  for  data-base  development  (Ref  36,  page  232). 

114.  The  first  [data-base]  project  attempted  by  an  organization  should  be 
regarded  as  a  seed  project,  deliberately  planned  and  used  to  train  a 
nucleus  of  data-base  staff  who  will  lead  the  way  on  other  projects 
(Ref  36,  page  233). 

115.  The  first  event  should  be  the  appointment  of  a  data  administrator 
with  enough  knowledge  and  at  a  high  enough  level  to  develop  the  data¬ 
base  strategy  and  select  an  organization-wide  data  description  lan¬ 
guage  and  data  dictionary  (Ref  36,  page  233). 

116.  ...the  corporate  data  administrator  has  a  policy-oriented  job  con¬ 
cerned  with  corporate  strategy  and  planning.  He  should  be  high 
enough  to  know  the  corporate  policies  and  politics,  and  have  strong 
powers  to  see  that  his  strategies  are  Implemented  (Ref  36,  page  261). 
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117.  Too  often  the  conceptual  clarity  of  shared  data  bases  becomes  clouded 
by  political  warfare.  To  resolve  the  bitter  arguments  that  ensue  the 
data-base  administrator  must  have  considerable  diplomacy  and  author¬ 
ity  (Ref  36,  page  266). 

118.  Great  care  must  be  devoted  to  (1)  establishing  expectations  that  can 
have  a  reasonable  probability  of  attainment,  (2)  determining  the  de¬ 
gree  of  commitment  by  which  management  is  willing  to  bind  Itself,  and 
(3)  formulating  implementation  guidelines  that  match  the  expectations 
and  commitment  (Ref  38,  page  13). 

119.  The  payback  from  the  Data  Resource  Management  Investment  will  not  be 
immediate;  two  to  five  years  for  the  start-up  investment  is  a  reason¬ 
able  expectation  (Ref  38,  page  14). 

120.  Do  put  some  high-level  focus  upon  Data  Resource  Management,  other 
than  the  issuance  of  policies,  directives,  instructions  or  regula¬ 
tions.  A  high-level  executive  or  staff  officer  should  be  publicly 
designated  as  the  person  who  will  either  be  held  accountable  for  Data 
Resource  Management  Implementation,  or  who  will  at  least  review  and 
report  upon  compliance  and  upon  the  benefits  realized  (Ref  38,  page 
17). 

121.  Don't  place  primary  responsibility  for  the  Data  Resource  Management 
function  under  the  top  "data  processing”  officer  [unless  all  of  the 
following  conditions  are  met]:  (a)  he  has  demonstrated  an  ability  to 
formulate  sound  organization-wide  policies  and  procedures,  (b)  he  is 
well  removed  from  the  operational  management  of  major  computer  cen¬ 
ters,  (c)  he  has  a  solid  grasp  of  program  missions  and  activities, 
and  (d)  he  has  a  keen  interest  in  paperwork  management  in  addition  to 
data  processing  management,  and  understands  and  appreciates  the  na¬ 
ture  and  role  of  manual  (non-automated)  information  systems  (ref  38, 
page  18). 

122.  The  federal  government  needs  to  upgrade  the  training  and  career  de¬ 
velopment  required  for  functional  managers,  reclassify  personnel 
skilled  in  the  management  or  use  of  information  technology,  and  es¬ 
tablish  appropriate  career  pathB  for  such  persons  (Ref  43,  page  14). 

123.  Firms  preparing  to  meet  the  challenges  of  the  1980s  will  need  a  capa¬ 
ble  and  sophisticated  manager  of  corporate  information.  An  organiza¬ 
tion's  success  in  the  coming  decade  will  be  dependent  in  large  part 
on  successfully  managing  its  information  resources.  Executives  re¬ 
sponsible  for  corporate  information  management  will  require  skills 
far  beyond  those  of  the  traditional  data  processing  manager  (Ref  47, 
page  114). 
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APPENDIX  B 
"HOW  TO  SUCCEED" 


The  lists  which  follow  are  excerpts  from 
Chapter  26  of  Reference  36:  James  Martin, 
PRINCIPLES  OF  DATA-BASE  MANAGEMENT, 
@1976,  pp.  319-323.  Reproduced  by 
permission  of  Prentice-Hall,  Inc. , 
Englewood  Cliffs,  N.J. 


James  Martin  is  the  author  of  over  twenty  books  on  different 
aspects  of  computing  and  computers,  including  database  design 
and  administration.  He  was  with  the  IBM  System  Research  In¬ 
stitute  for  ten  years.  At  this  time  he  is  an  independent  con¬ 
sultant  and  the  Chairman  of  the  board  of  two  private  companies, 
one  concerned  with  teleprocessing  and  communications,  the  other 
with  corporate  planning,  information  management,  and  database 
technology  (Database  Design,  Inc.  (DDI)). 

Martin  and  DDI  have  been  consultants  to  several  large 
corporations,  helping  them  construct  a  management-level  plan 
for  the  development  of  those  "subject  databases"  which  make 
up  the  corporate  database. 
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Reasons  for  Long-Term  Data-Base  Successes  and  Failures 


Reasons  for  Success  Reasons  for  Failure 

or  Disappointment 


Top  management  understand¬ 
ing  and  support  of  the  objec¬ 
tives,  and  determination  to 
make  the  data  bases  a  valuable 
corporate  resource. 

Concentration  on  well-specified, 
profitable  uses  of  the  data  bases. 


Development  of  data  bases 
which  relate  to  corporate  sub¬ 
jects,  rather  than  computer  ap¬ 
plications. 

A  planned  step-by-step  buildup 
of  applications  of  the  subject 
data  bases,  with  each  step  be¬ 
ing  suitably  small  and  easy. 

Corporate-wide  planning  by  a 
high-level  competent  data  ad¬ 
ministrator. 

Conversion  planning  that  per¬ 
mits  the  old  non-data-base  pro¬ 
grams  to  coexist  with  the  new. 
This  requires  well-tested  con¬ 
version  programs  which  create 
the  data  files  required  by  the 
old  programs. 

All  persons  are  thoroughly  edu¬ 
cated  at  a  level  appropriate  to 
their  function. 

Tight  Technical  control  by  the 
data-base  administrators. 


.  Dissenting  political  factions  who 
prevent  the  integration  which 
can  maximize  the  value  of  data. 


.  Overselling  "Management  In¬ 
formation  Systems"  (especially 
MIS  for  top  Management). 


.  Plans  for  the  installation  of  a 
grandiose  all-embracing  system. 


.  Fragmented  plans  by  noncom¬ 
municating  groups. 

.  Inadequate  attention  to  coex¬ 
istence  of  the  old  and  new; 
attempts  to  rewrite  too  many 
old  programs. 


.  Lack  of  understanding  of  data¬ 
base  principles  or  implementa¬ 
tion  requirements. 

.  Inadequate  CPU  power  or  main 
memory. 

Failure  to  estimate  response 
times  or  maximum  throughput. 
Failure  to  monitor  usage  and 
performance. 


Reasons  for  Success 


Reasons  for  Failure 
or  Disappointment 


Adoption  of  a  corporate-wide 
data  description  language.  (The 
software  will  change  while  the 
schema  data  descriptions  re¬ 
main  the  same . } 

Adoption  of  proven  state-of- 
the-art  software  with  both  logi¬ 
cal  and  physical  data  independ¬ 
ence. 


Through  end-user  involvement 
in  the  data-base  design. 

Employment  by  end  users  of  a 
powerful  easy-to-use  data-base 
interrogation  language. 

Recognition  of  the  vital  nature 
of  a  data  dictionary  and  system 
— Naming  standards 
— Update  control 
— Version  Synchronization 

Program  specifications  contain¬ 
ing  full  details  of  types  and  se¬ 
quences  of  date-base  accesses, 
thoroughly  reviewed  with  struc¬ 
tured  "walk-throughs”  with  the 
data-base  administrator  present. 


Failure  to  select  appropriate 
physical  data  structures. 

.  Use  of  multiple  separate  incom¬ 
patible  data-base  management 
systems. 


.  Writing  your  own  data-base 
management  facilities  or  modi¬ 
fying  existing  software.  (In  the 
long  run  this  is  usally  a  disas¬ 
ter.  ) 

.  Ill-defined  user  requirements. 


.  Casual  approach  to  library  con¬ 
trol. 


.  Lack  of  a  comprehensive  sys¬ 
tem  testing  plan  Including  the 
testing  of  compatibility  with  the 
surviving  old  applications. 

.  Inadequate  controls  on  data  ac¬ 
curacy  or  quality. 
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Reasons  for  Success 


Reasons  for  Failure 
or  Disappointment 


"Keep  it  simple." 


Careful  selection  of  the  first 
data-base  project.  The  first  pro¬ 
ject  should  be  chosen  to  maxi¬ 
mize  the  chances  of  success, 
and  to  act  as  a  seed  project  used 
to  develop  expertise  (see  next 
table). 

An  appropriate  mix  of  central¬ 
ized  standardization  and  guid¬ 
ance,  and  decentralized  imple¬ 
mentation. 

Technical  management  has  a 
business  orientation. 


.  Inadequate  security  or  embez¬ 
zlement  controls. 

.  Excessive  complexity.  Confused 
thinking. 


.  Lack  of  centralized  guidance 

leading  to  a  proliferation  of  in¬ 
compatible  systems. 

.  Excessive  centralized  control  by 
a  group  out  of  touch  with  the 
reality  of  local  operations  and 
problems. 


The  First  Project  is  Critical  to  the  Acceptance  of  the 
Data-Base  Route  and  Needs  to  be  Seen  to  Succeed 


Reasons  for  Success  on 
the  First  Project 


A  worthwhile  profitable  new 
project  with  its  own  “bottom- 
line"  payoff. 

Project  visibility. 


A  relatively  simple  project. 


Management  commitment  to  fu¬ 
ture  data-base  use. 

A  strong  technically  competent 
project  lader  who  is  respected 
above  and  below. 

Proven  bug-free  software  likely 
to  be  of  lasting  Importance. 

Very  thorough  education  of  the 
individuals  involved. 

A  project  without  a  critical 
deadline. 

Less  than  12  hours  on-line  per 
day. 

Thorough  assessment  of  the 
hardware  requirements. 

Data  bases  with  a  high  potential 
for  sharing  with  other  applica¬ 
tions  in  the  future. 


Reasons  for  Failure 
or  Disappointment 


Replacement  of  an  existing  sys¬ 
tem  without  adding  new  func¬ 
tion.  (All  this  will  prove  is  that 
data-base  systems  are  more  ex¬ 
pensive.  ) 

A  complex  or  grandiose  begin¬ 
ning. 

The  project  is  approached  in  a 
skeptical  “evaluation"  mode. 


The  latest  software  wonder. 


Inadequate  manpower  or  too 
short  a  schedule. 

On-line  24  hours  per  day. 

Inadequate  CPU  power,  main 
memory,  or  access  speed. 
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Reasons  for  Success  on 
the  First  Project 


Reasons  for  Failure 
or  Disappointment 


1 


! 

! 

A  high  degree  of  interation 
with  other  current  applications. 

The  solving  of  problems  put 
off  for  later. 

Very  thorough  system  testing 
and  training  of  user  groups. 


Careful  design  and  thorough 
testing  of  conversion  aids. 

Thorough  attention  to  detail. 
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APPENDIX  D 


ACSAC 

AMETA 

AVRADCOM 

DA 

DARCOM 

DMIS 

DOD 

GAO 

GSA 

NBS 

OMB 

SECO 

TSARCOM 


ABBREVIATIONS  FOR  FEDERAL  AGENCIES 


Assistant  Chief  of  Staff  for  Automation  and 
Communications  (directs  a  major  functional 
element  within  DA  HQS) 

Army  Management  Engineering  Training  Agency 

Aviation  Research  and  Development  Command 
(a  major  subordinate  command  of  DARCOM) 

Department  of  the  Army 

Development  and  Readiness  Command 
(a  major  command  of  DA) 

Directorate  for  Management  Information  Systems 
(a  functional  element  within  many  DARCOM 
subordinate  commands) 

Department  of  Defense 

General  Accounting  Ofice 

General  Services  Administration 

National  Bureau  of  Standards 

Office  of  Management  and  Budget 

Scientific  and  Engineering  Computing  Office 
(now  the  Scientific  and  Engineering  Computing 
Branch,  a  functional  element  of  AVRADCOM) 

Troop  Support  and  Aviation  Readiness  Command 
(a  major  subordinate  command  of  DARCOM) 
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